Segfaulting programs with GHC 6.4.1

[Simon Marlow]

On 21 October 2005 13:27, John Goerzen wrote:

> It wasn't from my build tree, but:
> 
> jgoerzen at 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 <s34n_info+0>:       mov    %edi,0x8(%esp)
> 0x080ba838 <s34n_info+4>:       mov    %edi,%eax
> 0x080ba83a <s34n_info+6>:       add    $0x8,%eax
> 0x080ba83d <s34n_info+9>:       mov    %eax,%edi
> 0x080ba83f <s34n_info+11>:      cmp    0x5c(%ebx),%eax
> 0x080ba842 <s34n_info+14>:      ja     0x80ba86b <s34n_info+55>
> 0x080ba844 <s34n_info+16>:      mov    0x0(%ebp),%edx
> 0x080ba847 <s34n_info+19>:      mov    0x4(%esi),%eax
> 0x080ba84a <s34n_info+22>:      cmpb   $0x0,(%eax,%edx,1)

the crash is here ^^^  it does appear to be something string-related,
because that instruction isn't a common one in GHC-generated code -
comparing a byte against zero, with a non-trivial addressing mode, looks
very much like a string traversal.

Do you have any other CString-related code in your program?

Cheers,
	Simon