RE: [Haskell-cafe] Project postmortem
On 18 November 2005 14:42, Joel Reymont wrote:
On Nov 18, 2005, at 1:55 PM, Simon Marlow wrote:
You can get debugging output by compiling your program with -debug, and then running it with some of the -D<something> options (use +RTS -? for a list, +RTS -Ds is a good one to start with).
I'm still working on a repro case but here's what I get...
+RTS -Ds ... scheduler: checking for threads blocked on I/O sched: -->> running thread 1103 ThreadRunGHC ... sched: --<< thread 1103 (ThreadRunGHC) stopped: is blocked on an MVar all threads: thread 1225 @ 0x1539000 is not blocked thread 1224 @ 0x1506aa4 is not blocked thread 1223 @ 0x15066a4 is not blocked ... scheduler: checking for threads blocked on I/O sched: -->> running thread 1107 ThreadRunGHC ... Segmentation fault
1107 is not blocked in the list of all threads. What options should I try next?
That doesn't tell us much unfortunately. Can you send a disassembly of the block in which the crash happened? Is it always the same block, BTW? Does changing the heap size (+RTS -H<size>) have any effect? Cheers, Simon
On Nov 18, 2005, at 2:47 PM, Simon Marlow wrote:
That doesn't tell us much unfortunately. Can you send a disassembly of the block in which the crash happened?
Is it always the same block, BTW? Does changing the heap size (+RTS -H<size>) have any effect?
I don't think changing the heap size has any effect. I tried a run with -H512m and the only difference was that it crashed at 0x00000005 with the same kernel protection failure. The address for s34n_info is the same, everything else the same, including stack trace and addresses and offsets in it. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x0024ef88 in s34n_info () (gdb) where #0 0x0024ef88 in s34n_info () #1 0x00211eb4 in StgRunIsImplementedInAssembler () at StgCRun.c:576 #2 0x0020f048 in schedule (mainThread=0x1100360, initialCapability=0x2fd508) at Schedule.c:932 #3 0x0020fff0 in waitThread_ (m=0x1100360, initialCapability=0x0) at Schedule.c:2156 #4 0x0020fed4 in scheduleWaitThread (tso=0x13c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x0020cd70 in rts_evalLazyIO (p=0x29216c, ret=0x0) at RtsAPI.c:459 #6 0x001d80fc in main (argc=2212180, argv=0x2fd508) at Main.c:104 (gdb) disas 0x0024ef88 Dump of assembler code for function s34n_info: 0x0024ef70 <s34n_info+0>: mr r10,r25 0x0024ef74 <s34n_info+4>: addi r9,r25,8 0x0024ef78 <s34n_info+8>: mr r25,r9 0x0024ef7c <s34n_info+12>: cmplw cr7,r9,r26 0x0024ef80 <s34n_info+16>: bgt- cr7,0x24efb4 <s34n_info+68> 0x0024ef84 <s34n_info+20>: lwz r2,4(r14) 0x0024ef88 <s34n_info+24>: lbzx r0,r2,r15 0x0024ef8c <s34n_info+28>: cmpwi cr7,r0,0 0x0024ef90 <s34n_info+32>: bne- cr7,0x24efc4 <s34n_info+84> 0x0024ef94 <s34n_info+36>: lis r2,42 0x0024ef98 <s34n_info+40>: lwz r2,20668(r2) 0x0024ef9c <s34n_info+44>: stw r2,4(r10) 0x0024efa0 <s34n_info+48>: stw r15,0(r9) 0x0024efa4 <s34n_info+52>: addi r14,r9,-4 0x0024efa8 <s34n_info+56>: lwz r29,0(r22) 0x0024efac <s34n_info+60>: mtctr r29 0x0024efb0 <s34n_info+64>: bctr 0x0024efb4 <s34n_info+68>: li r0,8 0x0024efb8 <s34n_info+72>: stw r0,108(r27) 0x0024efbc <s34n_info+76>: lwz r29,-4(r27) 0x0024efc0 <s34n_info+80>: b 0x24efac <s34n_info+60> 0x0024efc4 <s34n_info+84>: addi r15,r15,1 0x0024efc8 <s34n_info+88>: addi r25,r9,-8 0x0024efcc <s34n_info+92>: lis r29,37 0x0024efd0 <s34n_info+96>: addi r29,r29,-4240 0x0024efd4 <s34n_info+100>: b 0x24efac <s34n_info+60> 0x0024efd8 <s34n_info+104>: .long 0x21 0x0024efdc <s34n_info+108>: .long 0x240000 End of assembler dump. -- http://wagerlabs.com/
Folks, This is not quite the error that I was expecting but they could be related, I'm not sure. In any case, you can retrieve the repro project thusly: darcs get http://test.wagerlabs.com/postmortem You need OpenSSL to build these so don't forget to add -lssl -lcrypto to either ghc or ghci. I would appreciate if we could all collectively look at this as things are either wierd or I'm missing something obvious. I will apply any patches sent to me. I run like this: ghci -fglasgow-exts -lssl -lcrypto :l Server main ghci -fglasgow-exts -lssl -lcrypto :l Client main I get in the server window: interactive: unknown exception 14:51:39: ThreadId 1: Accepted new connection: {handle: <socket: 5>} 14:51:39: ThreadId 1: Verify locations: 1 14:51:39: ThreadId 1: sslGetError: 2 14:51:39: ThreadId 4: Starting SSL handshake... 14:51:39: ThreadId 4: Reading from BIO... 14:51:39: ThreadId 4: Waiting for BIO 0x01108670 14:51:39: ThreadId 4: waitForBio: gotta wait a bit... If you look at SSL.hs you will see that I'm calling threadDelay right after this message. No other messages are produced. This tells me that threadDelay is throwing an exception. Why would it, though? And how can I tell what the exception is? If I comment out the threadDelay then I get the exception somewhere in the expect code after bytes are sent to the other side. Overall, my intent is to get this to work for 1 thread and then try, say, 5 or 10 thousand. Thanks, Joel
test.wagerlabs.com seems really slow for me right now. I've mirrored the repo on my own machine (might not be 100% reliable, but should stay up nearly all of the time). The mirror address is http://vx.hn.org/postmortem/ - Cale On 18/11/05, Joel Reymont <joelr1@gmail.com> wrote:
Folks,
This is not quite the error that I was expecting but they could be related, I'm not sure. In any case, you can retrieve the repro project thusly:
darcs get http://test.wagerlabs.com/postmortem
You need OpenSSL to build these so don't forget to add -lssl -lcrypto to either ghc or ghci.
I would appreciate if we could all collectively look at this as things are either wierd or I'm missing something obvious. I will apply any patches sent to me.
I run like this:
ghci -fglasgow-exts -lssl -lcrypto :l Server main
ghci -fglasgow-exts -lssl -lcrypto :l Client main
I get in the server window:
interactive: unknown exception
14:51:39: ThreadId 1: Accepted new connection: {handle: <socket: 5>} 14:51:39: ThreadId 1: Verify locations: 1 14:51:39: ThreadId 1: sslGetError: 2 14:51:39: ThreadId 4: Starting SSL handshake... 14:51:39: ThreadId 4: Reading from BIO... 14:51:39: ThreadId 4: Waiting for BIO 0x01108670 14:51:39: ThreadId 4: waitForBio: gotta wait a bit...
If you look at SSL.hs you will see that I'm calling threadDelay right after this message. No other messages are produced. This tells me that threadDelay is throwing an exception.
Why would it, though? And how can I tell what the exception is? If I comment out the threadDelay then I get the exception somewhere in the expect code after bytes are sent to the other side.
Overall, my intent is to get this to work for 1 thread and then try, say, 5 or 10 thousand.
Thanks, Joel
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Cale Gibbard -
Joel Reymont -
Simon Marlow