00:24:22 -!- prxq [~mommer@mnhm-590c048c.pool.mediaWays.net] has quit [Quit: Leaving] 01:51:58 edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has joined #sbcl 01:52:46 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 02:33:12 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 03:16:01 echo-area [~user@182.92.247.2] has joined #sbcl 04:01:44 huangjs [~huangjs@69.84.244.131] has joined #sbcl 06:09:05 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: Leaving] 07:21:52 -!- wbooze [~wbooze@xdsl-78-35-156-138.netcologne.de] has quit [Read error: Operation timed out] 07:34:26 sdemarre [~serge@91.176.197.223] has joined #sbcl 07:37:11 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 09:44:01 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 09:55:45 prxq [~mommer@mnhm-5f75dc2e.pool.mediaWays.net] has joined #sbcl 11:41:50 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 11:43:28 tcr1 [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 11:45:03 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 252 seconds] 12:05:18 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:09:15 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 12:16:45 Thra11 [~thrall@175.106.113.87.dyn.plus.net] has joined #sbcl 12:40:33 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Read error: Connection reset by peer] 12:57:07 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:25:18 huangjs [~huangjs@69.84.244.131] has joined #sbcl 13:44:35 -!- loke_ [~elias@bb115-66-85-121.singnet.com.sg] has quit [Remote host closed the connection] 13:56:32 -!- tcr1 [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 14:02:34 why does target-thread.lisp has a lot of #+sb-thread? 14:02:54 isn't loading it implies that sb-thread is present? 14:03:05 -!- specbot [~specbot@tiger.common-lisp.net] has quit [Disconnected by services] 14:03:08 specbot [~specbot@tiger.common-lisp.net] has joined #sbcl 14:04:31 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Remote host closed the connection] 14:04:40 |3b|` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 14:04:42 <_8david> don't think so. The idea is that user code / libraries / whatever that doesn't actually need to create threads but wants to be "thread-aware" can use certain functions. 14:05:10 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [Ping timeout: 244 seconds] 14:06:04 <_8david> Extreme example: CAS isn't even dependent on sb-thread, but merely on :compare-and-swap-vops, so if you're building on x86 or ppc without sb-thread, you can still use CAS stuff. There just isn't going to be a second thread competing with you :-). 14:06:41 ivan`` [~ivan@unaffiliated/ivan/x-000001] has joined #sbcl 14:06:51 is there any clever way to figure what causes the binding stack to exhaust? 14:06:56 which variable 14:07:57 <_8david> Well, I'd iterate over the stack and print the contents (from C code) as mentioned yesterday. 14:08:09 well, i don't know how to do that 14:10:31 <_8david> untested, just thinking out loud: 14:10:37 <_8david> struct thread *th = arch_os_get_current_thread(); struct binding *ptr, *start = th->binding_stack_start; for (ptr = get_binding_stack_pointer(th); ptr > start; ptr--) { fprintf(stderr, "%x %x\n", ptr->symbol, ptr->value); } 14:11:24 and where should that be? inside handle_guard_page_triggered? 14:12:26 <_8david> yeah, I suppose. 14:12:38 <_8david> Or at the expense two 3 more LOC, define it properly as a new monitor command :-), seems useful enough. 14:12:57 well, binding stack exhaustion doesn't land into ldb 14:13:34 <_8david> aha. that's a pity really. Clearly we need --lose-on-even-the-slightest-hint-of-corruption. 14:15:04 well, i can go into ldb manually, but i really don't know what to do with it except for getting backtraces 14:15:13 <_8david> (If I had a euro for every time a developer has had to type (define-alien-routine ("monitor_or_something" monitor) void), I'd be rich!) 14:15:43 perhaps it should be defined somewhere? 14:16:11 the last two functions are 13: Foreign function call_into_lisp, fp = 0x7ffff01eded8, ra = 0x4309cf 14: Foreign function post_signal_tramp, fp = 0x7ffff01edf60, ra = 0x430ba0 14:16:11 14:17:00 did you see yesterday that the problem only happens when run from the initial thread? 14:21:28 -!- sdemarre [~serge@91.176.197.223] has quit [Ping timeout: 256 seconds] 14:22:32 <_8david> can you paste the whole stacktrace? 14:22:59 the ldb one strangely cut-off after the two of these 14:23:06 <_8david> but it's not necessarily informative; if we're pushing to the binding stack without popping back, the problem is somewhere else. 14:23:33 the lisp side backtrace isn't any more informative either 14:23:44 <_8david> stassats: well, wait, if this is the same situation as with the SBCL_DYNDEBUG output that you made available earlier -- note that you're getting two signals: the BSP overflow, and then a follow-up segfault. 14:24:31 well, i see no segfaults 14:24:51 visually, i mean 14:25:11 <_8david> I.e. we don't expect debuggability on the second disastrous signal; we want to debug the very moment the first signal struck. I.e., plug a second lose() call into the handle_guard_page_triggered function. 14:26:01 <_8david> I'm referring to http://paste.lisp.org/display/134224#1 14:26:14 <_8david> First you're overflowing the binding stack: fault_address = 0x7ffff02e0000, sp = 0x200ff000, &csp = 0x7ffff03f0000 14:26:20 <_8david> Then you're crashing with a second signal: fault_address = 0x100054daa8, sp = 0x200ff000, &csp = 0x7ffff03f0000 14:26:50 well, i can redo that test, because that time it was crashing on pthread_join 14:27:36 <_8david> handle_guard_page_triggered has two cases for the binding stack. First a lose() for the non-guard-page case. Then fancy stuff for the guard page. 14:28:07 <_8david> We'd want to get rid of the fancy stuff and just clearly lose() like the upper case. 14:29:05 Thra11_ [~thrall@87.115.52.221] has joined #sbcl 14:29:05 <_8david> Well, actually, leave the protect_foo() calls in. Just call lose in place of the fprintf(stderr, "INFO: Binding stack guard page unprotected\n"). 14:30:55 _8david: http://paste.lisp.org/display/134224#3 14:31:34 *_callback are printed on the cpp side before calling back 14:32:07 -!- Thra11 [~thrall@175.106.113.87.dyn.plus.net] has quit [Ping timeout: 260 seconds] 14:33:20 <_8david> ah, sorry, the second signal is just a wp violation. 14:33:30 <_8david> As you can tell, I'm a _little_ distracted. Sorry about that. 14:33:48 *_8david* <- smug ex-Lisper, not doing any actual debugging 14:33:55 i guess it'd be interesting also print the current qt thread before calling bug 14:43:47 the last 4 callbacks are not from a foreign thread, and all return before the exhaustion 14:52:26 the idea of a test-case which calls back both from a new thread and from the initial didn't result in any errors 14:54:15 wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has joined #sbcl 14:55:11 sdemarre [~serge@91.176.197.223] has joined #sbcl 14:56:47 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 15:01:16 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 15:03:56 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 255 seconds] 15:16:51 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:17:08 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 15:31:46 _8david: i see bind_variable(GC_INHIBIT, T, th); in attach_thread, but unbind is nowhere to be seen 15:32:35 <_8david> yeah, but we kill the whole "struct thread" (including the binding stack) upon detach. Next time around, you get a fresh "struct thread", and a new, empty binding stack. 15:32:44 ok, that's what i thought 15:33:44 <_8david> our BSP stuff is very easy to fool though, because there are no assertions for anything. I had a lot of fun on PPC with unwinds that didn't reset the BSP. 15:35:44 <_8david> It's a good thing Qt isn't using exceptions, because unwinds out of the callback wouldn't be... pleasant. 16:33:06 -!- sdemarre [~serge@91.176.197.223] has quit [Read error: Operation timed out] 16:41:17 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 18:49:52 sdemarre [~serge@91.176.197.223] has joined #sbcl 19:11:38 i can actually trigger it without using callbacks 19:30:34 hm, it looks like it fails during webkit garbage collection 19:32:33 350 mbs of webkit debug symbols are really slow gdb down 19:44:32 fails somewhere in gatherConservativeRoots, this is not looking good 20:15:27 -!- wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has quit [Ping timeout: 252 seconds] 20:23:59 -!- edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has quit [Quit: panic] 21:10:32 -!- Thra11_ [~thrall@87.115.52.221] has quit [Ping timeout: 246 seconds] 21:20:24 wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has joined #sbcl 21:54:59 -!- wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has quit [Remote host closed the connection] 22:10:40 wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has joined #sbcl 22:18:17 huangjs [~huangjs@69.84.244.131] has joined #sbcl 22:37:34 -!- sdemarre [~serge@91.176.197.223] has quit [Read error: Operation timed out] 22:49:16 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 23:16:18 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:29:51 -!- prxq [~mommer@mnhm-5f75dc2e.pool.mediaWays.net] has quit [Quit: Leaving]