On Fri, Oct 21, 2005 at 09:52:50AM +0100, Simon Marlow wrote:

At this stage we need to resort to gdb. Run the version of the program compiled with -debug under gdb, and take a look at the backtrace when it crashes. Hopefully it'll be somewhere in the RTS, if it's somewhere in Haskell code you won't get an informative backtrace.

OK, here's what I've got. There's a little bit here -- no idea if this provides any clues. In fact, it looks pretty much the same as when I ran gdb against the core file that it created when it crashed -- but with the addition of the last few lines. Here are the useful bits: ThreadId 9: quix.us:70:9:/Software/mulinux/Newer Upload/mulinux-14r0.iso ThreadId 8: serpiente.dgsca.unam.mx:70:0:0/noticia_mex_mundo/nacional/febrero94/07/depo/07febdepo14.txt [New Thread -1416234064 (LWP 26413)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214252112 (LWP 26365)] 0x080ba84a in s34n_info () (gdb) bt #0 0x080ba84a in s34n_info () #1 0xb7ac8374 in ?? () #2 0xb7a01910 in ?? () #3 0xb7ac8764 in ?? () #4 0xb7a05bac in ?? () #5 0x00028738 in ?? () #6 0x08172728 in MainCapability () #7 0x00000002 in ?? () #8 0x00000001 in ?? () #9 0xb7ac266c in ?? () #10 0x00000001 in ?? () #11 0xb7ac8738 in ?? () #12 0x00000000 in ?? () #13 0x00000000 in ?? () ... [ thousands of lines of this deleted ] ... #1872 0x00000000 in ?? () #1873 0x00000000 in ?? () #1874 0x08174058 in ?? () #1875 0x08174058 in ?? () #1876 0xb7a774b4 in ?? () #1877 0xb79ff138 in ?? () #1878 0x08134aa5 in allocBlock () #1879 0x080ba95c in s3eu_info () I then tried running it under +RTS -DbStprPlmg. Here are the last few lines of output: group at 0xb7a9c000, length 32 blocks group at 0xb7ac0000, length 1 blocks Gen Steps Max Mutable Mut-Once Step Blocks Live Large Blocks Closures Closures Objects 0 2 256 0 0 0 64 0 0 1 3 9212 5 1 1 256 5565 0 0 87 342876 47 ThreadId 5: userserve.ucsd.edu:70:4:4ftp:Public:Communications Programs:FTP Software:HyperFTP14 folder:HyperFTP14.sea ThreadId 12: serpiente.dgsca.unam.mx:70:0:0/noticia_mex_mundo/nacional/febrero94/07/depo/07febdepo4.txt In other words, there was no debugging output immediately prior to the crash -- the last two lines are regular messages my program outputs.

If it's possible for us to reproduce the bug here, I'll happily take a look.

You will need a PostgreSQL installation, but with that, you can fire up the program -- probably need to run it about 3 or 4 times before it has enough data in the DB to keep all the threads busy -- and hopefully that will do it. I will try a test from scratch later today and make sure that the bug occurs then as well. Otherwise, I'll post a dump of my PostgreSQL database somewhere. It usually segfaults less than a minute after getting going full-speed. -- John