I'm developing a program with GHC-6.6. I've been on amd64, and haven't had problems, but now when I run the program on on x86 (after cleaning and recompiling), I'm getting a segfault. gdb isn't very helpful at all: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212873040 (LWP 26946)] 0x080b45b8 in s2EI_info () (gdb) bt #0 0x080b45b8 in s2EI_info () #1 0x081757a8 in ?? () #2 0x00000004 in ?? () #3 0xb7875278 in ?? () I am using some various bindings to some C libraries, some I have written and some written by others. But, I'm not able to figure out where to even begin looking for the problem. Any advice on how I might be able to better debug this? Would compiling unregistered help (I'll have to figure out how to build libraries for that)? Thanks, David Brown
David Brown wrote:
I'm developing a program with GHC-6.6. I've been on amd64, and haven't had problems, but now when I run the program on on x86 (after cleaning and recompiling), I'm getting a segfault.
gdb isn't very helpful at all: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212873040 (LWP 26946)] 0x080b45b8 in s2EI_info () (gdb) bt #0 0x080b45b8 in s2EI_info () #1 0x081757a8 in ?? () #2 0x00000004 in ?? () #3 0xb7875278 in ?? ()
I am using some various bindings to some C libraries, some I have written and some written by others. But, I'm not able to figure out where to even begin looking for the problem.
Any advice on how I might be able to better debug this? Would compiling unregistered help (I'll have to figure out how to build libraries for that)?
Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can. http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes Cheers, Simon
Simon Marlow
Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can.
http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
Nice! How complicated would it be to teach gdb about GHC's calling convention, stack format, etc. Anyone who knows? -Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052
Simon Marlow wrote:
David Brown wrote:
0x080b45b8 in s2EI_info ()
Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can.
http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
This looks quite helpful, but still like it is going to be a pain in the neck. I did figure a few things out last night. - I grepped all of the libraries going into the program, and found the s2EI_info defined in libHSbase.o - Thanks to the splitting, I un"ar"ed libHSbase.o into individual files, and found this label in a file that appears to be the code to 'Foreign.C.peekCAString'. This makes sense with the assembly shown. - It appears to be trying to dereference a NULL pointer. I'm going to try the back-in-time approach given to see if I can track down what is calling this. I discovered it isn't just x86, but appears to be this particular machine. My other machines work fine. There might be a library difference between the machines, or something like that. Thanks, David
David Brown wrote:
I discovered it isn't just x86, but appears to be this particular machine. My other machines work fine. There might be a library difference between the machines, or something like that.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212225872 (LWP 10128)]
0x080b3618 in s2EI_info ()
(gdb) pstk
0xb79ff6b4: 0x805d0b8
David Brown wrote:
Hmm. I recompiled 'zlib' with some extra tracing and now the problem doesn't happen. Even without the tracing it is fine. Must have been something wrong with the compiled library. Scary. But, everything is working fine now.
I figured out what the problem is. I've been working in a shared directory with both an amd64 and an x86 machines using the files. I've been going back and forth. I've been blowing away the 'dist' directory and rebuilding when moving from one platform to the other. However, what I missed is that the hsc2hs target files are placed alongside the source, not in the dist directory. I had been building zlib on x86 using the hs generated on an amd64 machine. The offsets in the structures were wrong. How difficult would it be to have Cabal store the target files in the 'dist' directory with everything else? This also makes revision control a little more challenging, because I have to hand-pick a few select .hs files to ignore, since the rest of my code is sitting right next to them. Thanks, David Brown
On Wed, 2007-02-28 at 09:32 -0800, David Brown wrote:
However, what I missed is that the hsc2hs target files are placed alongside the source, not in the dist directory. I had been building zlib on x86 using the hs generated on an amd64 machine. The offsets in the structures were wrong.
Ohh, nasty.
How difficult would it be to have Cabal store the target files in the 'dist' directory with everything else? This also makes revision control a little more challenging, because I have to hand-pick a few select .hs files to ignore, since the rest of my code is sitting right next to them.
That would be good. I don't suppose it's too hard, after all we put other generated modules in dist (the paths module). We then just have to add more -i search dirs. I'd be happy to review cabal patches along these lines. [ On the plus side, I'm glad it wasn't a bug in my zlib binding :-) ] Duncan
participants (4)
-
David Brown -
Duncan Coutts -
Matthias Neubauer -
Simon Marlow