Segfaulting programs with GHC 6.4.1

[Simon Marlow]

On 22 October 2005 03:25, John Goerzen wrote:

> Here's some more data.
> 
> I tried this program with three versions of GHC.
> 
> GHC 6.4 with forkIO: could not produce a segfault at all
> GHC 6.4 with forkOS: rapid segfault (<30 sec)
> 
> GHC 6.4.1 with forkIO: segfault in <5 min
> GHC 6.4.1 with forkOS: segfault in <1 min
> 
> GHC 6.5: same results as GHC 6.4.1
> 
> Now, I also obtained a backtrace from GHC 6.4 with forkOS.  Here's a
> bit of it:
> 
> #0  0x080c2e3e in ForeignziCziString_zdwpeekCAString_info ()
> #1  0xb7a9e868 in ?? ()
> #2  0x00000020 in ?? ()
> #3  0xb7ecb08c in _res () from /lib/tls/libc.so.6
> #4  0xb7ad80ec in ?? ()
> #5  0x00000004 in ?? ()
> #6  0x016b0d36 in ?? ()
> #7  0xb7ac3f9c in ?? ()
> #8  0x93c0cef9 in ?? ()
> #9  0x4359a1e1 in ?? ()
> #10 0x000742d3 in ?? ()
> #11 0x00000000 in ?? ()
> ....
> #2021 0x00000000 in ?? ()
> #2022 0xb7ed80a6 in __pthread_mutex_cond_lock () from
> /lib/tls/libpthread.so.0 #2023 0x080c2f4c in
> ForeignziCziString_zdwpeekCAString_info () 
> 
> now this is the first time something from pthread actually appeared,
> which is interesting.
> 
> The code surrounding that CAString_info is:
> 
> 0x080c2f44 <ForeignziCziString_zdwpeekCAString_info+356>:       and  
> %eax,(%eax) 0x080c2f46 <ForeignziCziString_zdwpeekCAString_info+358>:
> add    %al,(%eax) 0x080c2f48
> <ForeignziCziString_zdwpeekCAString_info+360>:       and    $0x0,%al
> 0x080c2f4a <ForeignziCziString_zdwpeekCAString_info+362>:       add  
> %al,(%eax) 0x080c2f4c <ForeignziCziString_zdwpeekCAString_info+364>: 
> movl   $0x80c2f10,0x0(%ebp) 0x080c2f53
> <ForeignziCziString_zdwpeekCAString_info+371>:       jmp    *(%esi)
> 0x080c2f55 <ForeignziCziString_zdwpeekCAString_info+373>:       nop
> 0x080c2f56 <ForeignziCziString_zdwpeekCAString_info+374>:       nop  

Hi John,

Thanks for trying to narrow this down.  At this stage it looks like some
kind of heap corruption.  Can you reproduce it on more than one machine?
(we have to rule out hardware failure, it's happened before and can cost
a lot of debugging time).

BTW, the stack trace isn't useful beyond the top element, the reason
being that GHC's virtual machine doesn't use the C stack.  gdb can
usually tell you which bit of code the crash happened in, but if it was
in Haskell code then you don't have any information from the C stack.

I'll need to reproduce it here.  Can you give me a set of instructions
to get me up to the right point?

Cheers,
	Simon