01:13:04 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 03:40:44 consolers [~additivit@59.92.56.101] has joined #ccl 06:27:21 -!- dmiles_afk [~dmiles@c-71-237-234-93.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer] 06:28:13 dmiles_afk [~dmiles@c-71-237-234-93.hsd1.or.comcast.net] has joined #ccl 06:46:37 -!- consolers [~additivit@59.92.56.101] has quit [] 09:44:15 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #ccl 11:15:52 dioxriane [~dioxirane@unaffiliated/dioxirane] has joined #ccl 11:18:48 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 11:49:34 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #ccl 11:53:20 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Client Quit] 11:53:36 -!- dioxriane [~dioxirane@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 12:17:01 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #ccl 12:24:37 -!- DataLinkDroid [~DataLinkD@CPE-124-183-103-29.lns14.ken.bigpond.net.au] has quit [Quit: Bye] 12:27:46 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Quit: leaving] 13:03:50 -!- Krystof [~user@81.174.155.115] has quit [Ping timeout: 246 seconds] 13:27:47 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #ccl 13:27:49 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Client Quit] 13:55:45 Krystof [~user@81.174.155.115] has joined #ccl 15:43:54 Fare [fare@nat/google/x-bmnvjcclebmlxgwx] has joined #ccl 15:44:36 There might be other factors at work, but I suspect that (ccl:optimize-generic-function-dispatching) makes the problem worse. 15:45:17 When I removed this form (that I realized we weren't calling before), the memory corruption looked like it happened less often (but unhappily, still happens) 17:22:56 and when it happens, the symptom is directly a Vector at 0x302004981acd has bogus header : 0x0 rather than a ctype error. 17:26:34 actually, I also got some ctype issues. 17:27:09 the check-gc-integrity bit might explain the 0x0 thing 17:31:34 sellout- [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has joined #ccl 18:03:44 fare: there are several words of 0s getting written to memory for no apparent reason. One of them is where the CTYPE's header should be. 18:06:46 I was told to look at bt:condition-thread which is not atomic on ccl, for lack of proper primitive. But I doubt this causes this symptom. 18:07:03 and why always (or often) that place? 18:08:52 Haven't been able to tell. 18:10:10 CCL:OPTIMIZE-GENERIC-FUNCTION-DISPATCHING isn't defined in CCL. I have no idea (exactly) of what it does, and don't know how to undo whatever it is. 18:13:12 maybe it's a 1.8 thing. M-. takes me to l1-clos.lisp 18:13:39 No, I'd just forgotten it and spoke too soon. 18:13:59 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #ccl 18:14:51 doesn't look like it causes the problem though 18:15:42 let me look if I fumbled anything about the way I save-application 18:17:51 that's where I want an omniscient debugger. 18:20:10 that would be good! :) 18:22:53 maybe with an x86 emulator written in java, we could use the OD. 18:26:03 would be more exotic using OCalm.. 18:28:24 OCalmOD or O__oD :) 18:36:21 there is an OCamlOD ? 18:45:53 I think only Java has an ODB 18:46:37 but an ODB seems a bluff, or not? 18:47:40 anyway now I'm busy with Mathemagix :) .. 18:49:58 -!- Fare [fare@nat/google/x-bmnvjcclebmlxgwx] has quit [Ping timeout: 252 seconds] 18:50:50 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Quit: bye] 19:04:39 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #ccl 19:54:51 Fare: you don't want to do this in the long term, but could you try building your application with (SAVE-APPLICATION ... :PURIFY NIL) ? 19:55:14 sure I can. 19:55:44 oh, let me send you the functions I was using before and after regarding save-application... 19:55:54 ok. 20:06:30 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 20:19:38 Fare [fare@nat/google/x-avurvvslotjsdftt] has joined #ccl 20:34:21 probably not the problem after all. 20:43:17 which is not? purify? 20:55:38 yes, Still not sure. Can't read large hex numbers due to insufficient caffiene. Need to fix that. 21:46:36 Yes. Better when eyes can focus ... in the image I'm looking at, a slot's type predicate function has been copied to readonly memory, which means that any constants it references should have been copied to a static memory area. The only constant is the CTYPE object, and it's a (bad) pointer to the dynamic heap. That's likely either a bug in the code that does "purification" before an image is saved, or a bug elsewhere that confuses the puri 21:46:36 fcation code, or (less likely) something thinking that it's safe to clobber the predicate function's constant. 23:26:14 Should have seen that a lot earlier.