00:08:53 ASau` [~user@217.118.90.233] has joined #sbcl 00:09:41 -!- ASau [~user@217.118.90.233] has quit [Remote host closed the connection] 00:14:12 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 248 seconds] 00:16:39 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 00:29:56 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 00:40:41 huangjs [~huangjs@69.84.244.131] has joined #sbcl 01:47:00 -!- ASau` [~user@217.118.90.233] has quit [Ping timeout: 248 seconds] 02:03:34 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 02:22:34 huangjs [~huangjs@69.84.244.131] has joined #sbcl 02:27:13 -!- huangjs [~huangjs@69.84.244.131] has quit [Client Quit] 02:29:06 huangjs [~huangjs@69.84.244.131] has joined #sbcl 02:47:50 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 02:55:48 huangjs [~huangjs@69.84.244.131] has joined #sbcl 03:46:56 edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has joined #sbcl 07:34:05 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:37:53 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 08:00:41 sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 08:39:06 -!- wbooze [~wbooze@xdsl-78-35-190-129.netcologne.de] has quit [Ping timeout: 244 seconds] 09:09:14 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 09:19:04 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 09:34:54 ASau [~user@217.118.90.245] has joined #sbcl 10:07:46 huangjs [~huangjs@69.84.244.131] has joined #sbcl 10:09:29 -!- huangjs [~huangjs@69.84.244.131] has quit [Client Quit] 11:11:35 -!- ASau [~user@217.118.90.245] has quit [Ping timeout: 252 seconds] 11:54:43 ASau [~user@217.118.90.219] has joined #sbcl 12:07:20 _8david: therep 12:12:00 <_8david> always here -- never not busy with other stuff though 12:12:27 so, i figured yesterday that it has something to do with JS garbage collections 12:13:33 not sure yet what part specifically 12:14:16 <_8david> (note to self: plane tickets are expensive around new year; should have planned / booked earlier) 12:15:04 <_8david> stassats`: so that happens on the safepoint branch, but we don't know whether master is affected, too, because you can't run this code without safepoints in the first place? Or is there hope of narrowing it down to certain features? 12:15:21 wouldn't they be expensive before that too? since the airline will know that it'll be able to sell all of them 12:16:00 _8david: maybe it doesn't happen on the safepoints, since without safepoints i can't test it due to foreign callbacks, but i can disable callbacks and test without them 12:16:30 will do that now 12:26:12 happens without safe-points too 12:29:00 _8david: and happens with 1.0.42, so, you're in the clear 13:19:33 <_8david> I've lost track; Is this one of the tests that also fails (in some way) with CCL or not? 13:19:47 no, ccl works fine 13:20:08 and it also works fine when started not from the initial thread 13:21:54 i.e. (test) fails, (sb-thread:make-thread #'test) does not 13:22:32 <_8david> Does it fail using ccl::call-in-initial-process? 13:23:55 nope 13:26:20 <_8david> It's easy then, let's all switch to Clozure. 13:27:39 well, it's a good option, but still 13:29:16 i need to figure out whether what webkit does is otherwise harmless and then construct an independent test-case 13:31:33 huangjs [~huangjs@69.84.244.131] has joined #sbcl 13:32:26 *stassats`* is amazed that qtwebkit debug symbols take 329MB 13:35:59 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 14:07:11 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:13:16 akovalenko [~akovalenk@95.73.220.136] has joined #sbcl 14:14:12 -!- akovalenko [~akovalenk@95.73.220.136] has quit [Client Quit] 14:23:28 -!- sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 14:32:55 wbooze [~wbooze@xdsl-78-35-184-210.netcologne.de] has joined #sbcl 15:09:40 -!- ASau [~user@217.118.90.219] has quit [Ping timeout: 248 seconds] 15:18:48 -!- flip214_ [~marek@86.59.100.100] has quit [Ping timeout: 264 seconds] 15:24:17 flip214 [~marek@86.59.100.100] has joined #sbcl 15:24:17 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 15:24:17 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 15:37:48 sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 16:07:16 oh, i get why slime fails with sb-dynamic-core, it tries to load old fasls, since the version didn't change 16:09:04 just as i resurrected build-system modifications allowing to rebuild sbcl after a runtime changes in 9 seconds 16:11:15 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 16:19:45 there was at least at some point *features-affecting-fasl-file-format* 16:21:14 ASau [~user@217.118.90.158] has joined #sbcl 16:27:32 -!- sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 16:38:09 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 16:41:29 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 16:46:52 huangjs [~huangjs@69.84.244.131] has joined #sbcl 16:48:41 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 16:59:24 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 17:09:45 huangjs [~huangjs@69.84.244.131] has joined #sbcl 17:23:14 <_8david> reading sbcl-devel. So, which Darwin user is willing to clean up what I left behind? 17:27:00 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 17:31:20 huangjs [~huangjs@69.84.244.131] has joined #sbcl 17:46:12 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 17:50:44 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 265 seconds] 17:51:43 so webkit wants to scan from 0x7ffff01ee0f8 to 0x7ffffffff000 17:52:17 and 7ffffffff000 is that end of what's marked as [stack] in /proc/maps, so it wants a hole lot of memory which is not its own 17:56:07 and it never wants to scan such a broad range when run from a non-main thread or from ccl 18:09:08 <_8david> How does that compare to the thread's original stack according to pthread_attr_getstack? 18:09:32 <_8david> (See attach_os_thread for sample code to find out.) 18:10:32 <_8david> Maybe the first address is the current stack pointer (on our stack) and the second address is the original stack's end. 18:11:16 <_8david> Would make sense, because the initial thread is the only one playing such shenanigans. 18:11:46 well, the only conclusion i'm reaching: don't run webkit from the initial thread 18:12:01 but then, another problem, when i close the window, i get the pthread_join error 18:13:34 <_8david> stassats`: that's a bad solution for many users though, because on some platforms, _only_ the initial thread is capable of running Qt at all. :-( 18:14:05 <_8david> So we really need to stop switching stacks. (I've only said it a few dozen times before, so I'll say it again.) 18:14:27 what does it mean to switch stacks? 18:16:19 <_8david> stassats`: We just recklessly frob the stack pointer registers to use an address within our struct thread. 18:16:48 <_8david> Meanwhile, the pthread still has an attr that indicates a completely different region, and that's presumably what Webkit is querying to find the stack end. 18:19:49 <_8david> I'm surprised there's still a pthread_join issue. Because previously (the problem that I've patched) were happening because we had been calling pthread_join on threads which weren't ours. 18:20:02 <_8david> Now, if we've still got such issues, one theory would be that C++, conversely, is calling pthread_join or pthread_cancel or _our_ threads. I think it shouldn't be doing that... 18:22:25 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 18:24:39 adding a breakpoint in gdb shows that pthread_join is called on our side only 18:30:18 and it's joining the thread created by (sb-thread:make-thread #'test) 18:30:47 while being in that thread 18:32:32 that's why it returns EDEADLK 18:36:26 <_8david> Did you already paste a backtrace for this specific pthread_join? 18:37:03 nope, pasting show output right now 18:37:27 http://paste.lisp.org/display/134224#4 18:38:13 so, it's attaching to itself 18:38:50 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 18:40:34 _8david: and the backtrace http://paste.lisp.org/display/134224#5 18:41:25 so, it's a callback 18:42:58 <_8david> yeah. 0x7fffefd8f700 is the decimal number in: [(nil)/(nil)] /exiting thread 140737217361664 18:43:41 that looks something i can construct a test-case 18:44:53 <_8david> So we have quit our Lisp thread (as far as we are concerned, but the pthread still needs to actually exit), have scheduled a post mortem for it, and now Qt is doing some bookkeeping upon thread exit (maybe). So we get a callback from a thread that isn't a true Lisp thread anymore. 18:46:39 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 18:47:49 so, what to do? 18:49:42 <_8david> 1. check whether that theory is correct (does the "pthread exit hook" which I'm assuming Qt is using even exist?) 18:49:52 <_8david> 2. if so, should be easy to produce a test case 18:50:04 <_8david> 3. ??? 18:50:07 <_8david> 4. problem solved 18:51:15 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 18:53:13 _8david: if it's only one failing test I am willing to consider it *sheesh, just get a real OS already* 18:57:15 <_8david> Krystof: hmm, we could try whether Linux builds with futexes disable also have the symptom 18:57:47 <_8david> *disabled. Anyway, too bad I'm not doing Common Lisp anymore :-) 18:58:17 sheesh, what is it with people getting jobs and stopping all their free labour 18:58:24 it's almost like it's a capitalist conspiracy 18:58:31 _8david: it's all C anyway 18:58:40 ah how I long for the days when we were all students and commies 19:04:17 (cliini, come back!) 19:45:30 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:46:57 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 19:51:48 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 19:58:28 -!- wbooze [~wbooze@xdsl-78-35-184-210.netcologne.de] has quit [Quit: none] 20:01:08 bummer, replicated what qt is doing, and it doesn't trigger the error 20:03:17 maybe it's not an exactly exact replication 20:03:17 20:07:42 oh, yay, reproduced 20:10:04 now at least i can offload it to someone who understands what he's doing 20:11:13 _8david: http://paste.lisp.org/display/134224#6 20:15:52 prxq [~mommer@mnhm-5f75f7c7.pool.mediaWays.net] has joined #sbcl 20:23:27 wbooze [~wbooze@xdsl-78-35-184-210.netcologne.de] has joined #sbcl 20:37:46 -!- Ober [jaimef@dns.mauthesis.com] has quit [Excess Flood] 20:38:36 ccl actually segfaults on this 20:39:40 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 20:40:02 and segfaults with the same thing on webkit, so, sbcl is no the only one 20:42:24 Krystof: the fact that that commit results in an OS specific failure is v. strange. 20:42:30 (i.e. par for the course on darwin) 20:42:46 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 20:46:21 ober [~user@96.24.70.135] has joined #sbcl 20:46:56 abcl survives both tests 20:47:24 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 20:51:41 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 20:54:32 -!- ober [~user@96.24.70.135] has quit [Read error: Connection reset by peer] 21:07:24 hydan [~user@ip-89-102-13-27.net.upcbroadband.cz] has joined #sbcl 21:14:01 -!- wbooze [~wbooze@xdsl-78-35-184-210.netcologne.de] has quit [Ping timeout: 252 seconds] 21:20:24 -!- edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has quit [Quit: lifetime expired] 21:29:29 -!- prxq [~mommer@mnhm-5f75f7c7.pool.mediaWays.net] has quit [Quit: Leaving] 21:44:23 -!- hydan [~user@ip-89-102-13-27.net.upcbroadband.cz] has quit [Ping timeout: 260 seconds] 21:47:40 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 21:52:24 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 22:22:07 wbooze [~wbooze@xdsl-78-35-189-199.netcologne.de] has joined #sbcl 22:47:57 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 22:52:43 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 265 seconds] 23:18:30 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:28:08 hm, webkit actually calculates stack bound correctly, but uses void* dummy; and then &dummy for the beginning of where it scans 23:28:13 could that ever make sense? 23:28:25 stassats`: yes. that gives it a top-of-stack marker. 23:28:50 not portable at all, but should work on all but the most fascist of compilers. We do the same. 23:29:03 but it disagrees with the what pthread_attr_getstack does 23:30:46 and with /proc/self/maps 23:32:30 when i extract a test case which does the same, it's correct 23:32:54 oh, not really, i misprinted 23:33:23 0x7fffff7ff000 + 0x800000 = 0x7ffffffff000, dummy: 0x7ffff01ef198 23:34:00 altstack? 23:34:21 what's that? 23:45:19 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 23:45:58 so it gets the beginning of stach from &dummy, and the end from pthread_attr_getstack 23:46:08 which spans a lot more than just stack 23:46:34 if there are two of them, whatever that means 23:50:46 bloody stackoverflow, it's not impossible to search for things about stacks 23:54:10 and all other implementations, &dummy is inside the stack 23:54:52 stassats`: is it on another stack, e.g. the one used for signal handling? 23:55:21 i just load a shared library 23:56:11 does sbcl implement foreign calls through signals or something? 23:59:54 stassats`: no. But with signal-based callbacks, who knows?