On Fri, Oct 21, 2005 at 10:28:51AM +0100, Simon Marlow wrote:
On 21 October 2005 10:20, John Goerzen wrote:
On Fri, Oct 21, 2005 at 09:52:50AM +0100, Simon Marlow wrote: #0 0x080ba84a in s34n_info () #6 0x08172728 in MainCapability () #1878 0x08134aa5 in allocBlock () #1879 0x080ba95c in s3eu_info ()
A couple more things to try: disassemble s34n_info to see where exactly it crashed, and if there are any calls in there you recognise, and 'grep s34n_info *.o' over your object files to see which object that symbol comes from.
It wasn't from my build tree, but:
jgoerzen@katherina:/usr/lib/ghc-6.4.1$ grep -ri s34n_info *
Binary file libHSbase.a matches
Binary file libHSdata.a matches
I unpacked libHSbase.a and found:
$ grep -ri s34n_info .
Binary file ./String__1.o matches
Binary file ./Posix__6.o matches (this one doesn't match if I omit -i)
Identical results from libHSdata.a.
I thought I would also look at s3eu_info. It too is in libHSbase.a:
$ grep -r s3eu_info .
Binary file ./Internals__19.o matches
Binary file ./String__1.o matches
objdump -x String__1.o yields, among other things:
...
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000068 l O .text 0000000c s34n_info
00000190 l O .text 00000008 s3et_info
000000c4 l O .text 00000008 s351_info
00000160 l O .text 00000008 s3eu_info
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 g O .data 00000004
ForeignziCziString_zdwpeekCAString_closure
0000000c g O .text 0000000c ForeignziCziString_zdwpeekCAString_info
00000000 *UND* 00000000 GHCziBase_Izh_con_info
00000000 *UND* 00000000 GHCziBase_Czh_con_info
00000000 *UND* 00000000 GHCziBase_ZC_con_info
00000000 *UND* 00000000 stg_gc_ut
00000000 *UND* 00000000 GHCziBase_ZMZN_closure
Now, I may be totally reading this wrong, but seeing several references
to Foreign and String made me think of CStrings. That made me
suspicious of this function. You may remember I asked about it on IRC,
and we thought it was OK:
msg :: String -> IO ()
msg l =
do t <- myThreadId
let disp = (show t) ++ ": " ++ l ++ "\n"
withCStringLen disp (\(c, len) -> hPutBuf stdout c len >> hFlush stdout)
This may be a complete red herring, but I just thought I'd bring it up.
Maybe it's a clue anyway.
Here's the disassemble output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1407190096 (LWP 31315)]
0x080ba84a in s34n_info ()
(gdb) disassemble s34n_info
Dump of assembler code for function s34n_info:
0x080ba834