00:00:08 well, no callbacks involved here 00:23:01 the address doesn't seem to be consistent with the address given to sigaltstack 01:07:10 <_8david> I don't think we need to worry about the altstack too much; if anyone has trouble running Qt code after stack overflow, the answer is "then don't do that". 01:08:13 <_8david> But so far your observations are confirming my assumption that Webkit asks the pthread for its stack, and hence doesn't know that our initial thread keeps its stack elsewhere. Correct? Or am I misunderstanding? 01:11:56 <_8david> And thanks for the other test case. Not that I've actually thought about it much yet, but I'm sure it's a fixable problem in principle :-). 01:12:50 <_8david> [I think I'd like to switch all platforms to IMMEDIATE_POST_MORTEM before even starting to think about more issues with the old post mortems.] 01:31:33 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 01:42:07 _8david: the problem is that it asks pthread for the end of the stack, and uses an address of a stack-allocated variable for the beginning 01:43:18 the resulting bound span several unrelated memory regions, upon reaching a protected one it faults 01:43:22 spans 01:47:57 <_8david> yeah 02:05:05 slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has joined #sbcl 02:15:22 cmm [~cmm@bzq-109-64-187-44.red.bezeqint.net] has joined #sbcl 02:16:09 -!- cmm- [~cmm@109.64.162.141] has quit [Ping timeout: 252 seconds] 02:18:15 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 244 seconds] 02:18:22 huangjs [~huangjs@69.84.244.131] has joined #sbcl 02:23:19 -!- slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has quit [Ping timeout: 246 seconds] 02:23:45 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 02:34:27 there seem to be no way to change that 02:34:45 are there any reason to not use the default stack? 02:38:47 once thread joining is fixed, having to run it in a new thread is not such a big deal 02:44:21 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 02:45:18 huangjs [~huangjs@69.84.244.131] has joined #sbcl 02:54:10 or can it be made so that it's near the default one so that stray references don't cause problems? 03:31:07 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 265 seconds] 03:36:36 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 03:48:08 kanru`` [~kanru@111-249-157-18.dynamic.hinet.net] has joined #sbcl 04:11:53 edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has joined #sbcl 04:12:19 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 04:38:46 huangjs [~huangjs@69.84.244.131] has joined #sbcl 06:49:20 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 246 seconds] 06:49:42 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 07:37:36 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 07:44:59 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [Ping timeout: 246 seconds] 07:47:20 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 07:58:56 sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 08:53:51 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 09:26:04 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 09:50:08 -!- wbooze [~wbooze@xdsl-78-35-189-199.netcologne.de] has quit [Ping timeout: 265 seconds] 10:33:00 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:53:22 huangjs [~huangjs@69.84.244.131] has joined #sbcl 11:35:04 ASau` [~user@217.118.90.197] has joined #sbcl 11:36:38 -!- ASau [~user@217.118.90.158] has quit [Ping timeout: 250 seconds] 11:55:14 -!- ASau` [~user@217.118.90.197] has quit [Remote host closed the connection] 11:55:36 ASau` [~user@217.118.90.197] has joined #sbcl 12:57:25 -!- sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 13:23:57 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 13:35:47 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Quit: trivial-irc-0.0.4] 13:54:14 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 13:54:22 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 13:54:26 tcr1 [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 14:02:38 -!- tcr1 [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 14:23:53 LiamH [~none@96.231.220.53] has joined #sbcl 14:31:47 <_8david> stassats: being able to contral the size of the initial thread's stack is one issue that comes to mind. 14:32:31 <_8david> Anyone know whether we can control that value (at link time or something, independently of ulimits and stuff)? 14:34:31 <_8david> (We could also, of course, just do the clozure thing and not run the REPL in the initial thread, meaning that we wouldn't have to worry much about how the initial thread is configured. Implies a push towards having threads on all platforms though, which isn't realistic yet.) 14:37:41 _8david: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4689767 doesn't look good 14:48:16 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 14:51:08 huangjs [~huangjs@69.84.244.131] has joined #sbcl 14:55:15 sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 14:56:49 <_8david> Aha. So the usual "Windows still doesn't work because it's oh so different" kind of issue where Windows is actually the only platform that makes any sense at all. 14:58:59 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 15:03:44 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 265 seconds] 15:29:57 -!- ASau` [~user@217.118.90.197] has quit [Ping timeout: 248 seconds] 15:37:50 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 16:12:04 -!- sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 17:06:31 sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 17:12:37 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Quit: trivial-irc-0.0.4] 17:46:24 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 17:49:49 wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has joined #sbcl 17:59:25 -!- wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has quit [Quit: none] 18:00:19 wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has joined #sbcl 18:15:33 -!- LiamH [~none@96.231.220.53] has quit [Quit: Leaving.] 18:16:23 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 18:28:28 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 18:36:58 -!- wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has quit [Ping timeout: 250 seconds] 18:53:45 _8david: one idea for solving key destrutctors calling back: the destructors are called several times if there are some non-null keys, so, put thread clean up routines onto a key with value 1, when the destructor is called and the value is 1, decrement it and do nothing, when it's called the second time with 0 do clean up 18:54:05 so the destructors which are called the first time are run before that and can call back 18:54:43 wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has joined #sbcl 18:54:47 doesn't guard against destructors which call back not on the first iteration, but i suppose the number of such is limited 19:21:26 prxq [~mommer@mnhm-5f75d65e.pool.mediaWays.net] has joined #sbcl 19:29:45 pthreads seem complicated, and yet lacking things 19:29:48 Fare [~fare@68-245-80-209.pools.spcsdns.net] has joined #sbcl 19:32:03 prxq_ [~mommer@vpn205-075.rzuser.uni-heidelberg.de] has joined #sbcl 19:33:59 ASau [~user@217.118.90.203] has joined #sbcl 19:36:20 -!- prxq [~mommer@mnhm-5f75d65e.pool.mediaWays.net] has quit [Ping timeout: 265 seconds] 19:52:37 -!- wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has quit [Quit: Client Quit] 20:03:53 LiamH [~none@96.231.220.53] has joined #sbcl 20:09:35 wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has joined #sbcl 20:11:52 -!- prxq_ is now known as prxq 20:27:54 -!- LiamH [~none@96.231.220.53] has quit [Ping timeout: 244 seconds] 20:35:42 -!- Fare [~fare@68-245-80-209.pools.spcsdns.net] has quit [Ping timeout: 250 seconds] 20:44:06 LiamH [~none@96.231.220.53] has joined #sbcl 21:27:51 -!- ASau [~user@217.118.90.203] has quit [Remote host closed the connection] 21:39:52 ASau [~user@217.118.90.203] has joined #sbcl 22:14:46 -!- edgar-rft [~GOD@HSI-KBW-091-089-005-153.hsi2.kabelbw.de] has quit [Quit: paranoid] 22:17:17 -!- wbooze [~wbooze@xdsl-78-35-181-18.netcologne.de] has quit [Ping timeout: 265 seconds] 22:19:41 -!- prxq [~mommer@vpn205-075.rzuser.uni-heidelberg.de] has quit [Quit: Leaving] 22:30:12 -!- sdemarre [~serge@252.179-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 22:37:51 wbooze [~wbooze@xdsl-78-35-136-243.netcologne.de] has joined #sbcl 23:09:01 -!- wbooze [~wbooze@xdsl-78-35-136-243.netcologne.de] has quit [Quit: Client Quit] 23:32:10 hydan [~user@ip-89-102-13-27.net.upcbroadband.cz] has joined #sbcl 23:48:47 -!- LiamH [~none@96.231.220.53] has quit [Ping timeout: 245 seconds]