00:42:25 jajcloz [n=jaj@pool-98-110-225-173.bstnma.fios.verizon.net] has joined #ccl 00:48:33 rme [n=rme@pool-70-104-96-75.chi.dsl-w.verizon.net] has joined #ccl 03:33:58 -!- jajcloz [n=jaj@pool-98-110-225-173.bstnma.fios.verizon.net] has quit [] 03:33:58 -!- mdc_mobile [n=mdc_mobi@c-76-119-233-23.hsd1.ma.comcast.net] has quit [Read error: 104 (Connection reset by peer)] 03:34:17 mdc_mobile [n=mdc_mobi@c-76-119-233-23.hsd1.ma.comcast.net] has joined #ccl 03:42:10 bfulgham_ [n=brent@adsl-69-234-124-120.dsl.irvnca.pacbell.net] has joined #ccl 06:09:12 -!- bfulgham_ [n=brent@adsl-69-234-124-120.dsl.irvnca.pacbell.net] has quit [] 06:46:14 -!- rme [n=rme@pool-70-104-96-75.chi.dsl-w.verizon.net] has quit [] 07:46:44 vy [n=user@nbvyazici.cs.bilkent.edu.tr] has joined #ccl 10:09:44 jajcloz [n=jaj@pool-98-110-225-173.bstnma.fios.verizon.net] has joined #ccl 13:30:46 -!- mdc_mobile [n=mdc_mobi@c-76-119-233-23.hsd1.ma.comcast.net] has quit [] 13:36:46 anRch [n=markmill@nmd.sbx07269.sauguma.wayport.net] has joined #ccl 15:05:02 anRch_ [n=markmill@12.147.116.251] has joined #ccl 15:10:49 -!- anRch [n=markmill@nmd.sbx07269.sauguma.wayport.net] has quit [Read error: 113 (No route to host)] 16:26:59 -!- anRch_ [n=markmill@12.147.116.251] has quit [] 16:44:43 -!- alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [] 16:53:54 alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 17:54:54 rme [n=rme@pool-70-104-96-75.chi.dsl-w.verizon.net] has joined #ccl 19:58:30 mdc_mobile [n=mdc_mobi@75-151-253-49-Pennsylvania.hfc.comcastbusiness.net] has joined #ccl 20:20:24 mdc_ [n=mdc_mobi@75-151-253-49-Pennsylvania.hfc.comcastbusiness.net] has joined #ccl 20:36:45 -!- mdc_mobile [n=mdc_mobi@75-151-253-49-Pennsylvania.hfc.comcastbusiness.net] has quit [Read error: 113 (No route to host)] 21:20:12 Fare [n=Fare@ita4fw1.itasoftware.com] has joined #ccl 21:20:32 hum. Is there a way to determine if a GC will be full or incremental? Or to force either mode? 21:20:57 (and is there a way to disable the dynamic-extent optimization?) 21:22:52 there's no way to force an ephemeral gc. 21:23:07 (gc) always does a full gc. 21:23:26 it does? good to know 21:23:54 *Fare* suspects that erroneous dynamic extent declarations were leading to random memory corruption -- but cannot prove it 21:31:53 (shadow 'dynamic-extent) and ignore unrecognized declaration warnings? :-) 21:33:10 I was thinking of that -- is there a way to make it automatically ignore them? 21:33:23 maybe (deftype dynamic-extent () t) ? 21:33:40 or something 21:35:03 anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has joined #ccl 21:36:27 I don't know if there's a way to ignore dynamic-extent declarations; maybe gz or gbyers would know. 21:37:16 I was just looking; I'd have guessed that there was such a way (maybe if DEBUG or SAFETY was high), but if there is I can't find it. 21:39:35 what is a good way to force a malloc + free, just to stress malloc? 21:39:59 (and hopefully discover if the corruption happened already) 21:40:34 (loop (ccl::free (ccl::malloc n))) 21:41:52 I wonder if enabling some malloc debugging options would help if you suspect that this is malloc-related? 21:42:15 I'm not sure what platform you're on, but both glibc and Darwin have options to detect double frees, frees of pointers not allocated, etc. 21:42:22 There might also be a "debugging malloc" library we could link against. Apple's malloc actually seems to have good debugging features. 21:42:47 There is a debugging malloc from Google that I have used in the past. 21:42:50 Linux's didn't look that good, but I may have missed something. 21:42:50 It's part of tcmalloc. 21:43:35 http://code.google.com/p/google-perftools/ 21:43:38 http://google-perftools.googlecode.com/svn/trunk/doc/heap_checker.html 21:43:59 I am sure that trying to run ccl under valgrind would be good for a laugh :-) 21:46:57 A long time ago (when MCL was an Apple product and Apple had decided to switch to the PPC), some people in Cupertino came to our lab and suggested that we run MCL through a binary translation program that they'd acquired and gotten good results with. I'm fairly sure that the translation program caught on fire. 21:47:41 :-) 21:54:48 *Fare* remembers Executor 21:54:59 I wonder if it ran CCL 21:55:51 I would guess "no". It had its own Toolbox implementation, and it was spotty if I remember correctly. 21:56:01 Basilisk II does run MCL. 21:58:02 nice 22:00:45 http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html 22:02:47 gbyers, is there a good abortfn to offer from CCL ? 22:03:00 e.g. something that would enter the debugger 22:04:22 I'm sure that we could figure something out. Googling; apparently, linking with -lmcheck is equivalent to calling mcheck() early enough, but some messages seem to indicate that mcheck isn't (or wasn't) thread-safe. 22:08:48 would LD_PRELOAD=/usr/lib/libmcheck.so do the trick? 22:09:33 (#_mcheck 0) complains > Error: value 0 is not of the expected type MACPTR. 22:10:01 (#+mcheck ccl:+null-ptr+) 22:11:13 (#_mcheck +NULL-PTR+) 22:11:22 err, (#_ ...), not (#+ ...). Right. 22:12:40 now to insert a mcheck early enough in the execution 22:13:13 It pretty much has to go in the lisp kernel, early in main(). 22:13:43 yup. 22:14:25 -!- mdc_ [n=mdc_mobi@75-151-253-49-Pennsylvania.hfc.comcastbusiness.net] has quit [] 22:14:30 looks like mcheck would only tell me what I already know, mostly, though 22:15:28 (but it would tell me when the corruption happened) 22:15:41 It might tell you earlier (when the problem is introduced, rather than when it causes a segfault.) 22:15:44 right. 22:16:24 *Fare* starts recompiling ccl... 22:16:37 (then qres with ccl) 22:17:33 The glibc page shows how to call mcheck from GDB. 22:33:04 thanks a lot for your support! 22:33:21 (going through more goose chasing efforts) 22:37:03 -!- Fare [n=Fare@ita4fw1.itasoftware.com] has quit ["Leaving"] 22:49:02 -!- anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has quit []