Re: Segfaulting programs with GHC 6.4.1

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 : and %eax,(%eax) 0x080c2f46 : add %al,(%eax) 0x080c2f48 : and $0x0,%al 0x080c2f4a : add %al,(%eax) 0x080c2f4c : movl $0x80c2f10,0x0(%ebp) 0x080c2f53 : jmp *(%esi) 0x080c2f55 : nop 0x080c2f56 : nop Hope this carries a clue somewhere. -- John