00:56:25 If somebody's on and can M-x slime, on a Win32 system : Run (loop for i from 1 do (progn nil)) <-- Does it fail within 5 minutes on an invalid memory access? 00:57:33 If it does, please report it as a bug. 00:58:16 I can get it to fail on 2 systems - but granted, both those win32s are configured in an identical manner. 01:24:19 I don't have a 32-bit linux CCL/Slime. Would you be able to run (loop for i from 1 do (progn nil)) for a while and see if it grenades? 01:40:46 I might try to make myself useful and chase this down. The fault fires as "Fault during read of memory address #x8 or some other low value - is this a memory address? Is there a call I can use to obtain the memory address of a reference? 01:41:19 A backtrace might be helpful. 01:43:35 I put the backtrace in the bug - add-bignum-and-fixnum and %Add-with-carry; but that may just be that that's all that the loop is doing and corruption is elsewhere 01:54:57 -!- segv_ [n=mb@p4FC1DC7A.dip.t-dialin.net] has quit [] 02:12:26 I just tried in a command-line lisp and it's been counting away for 20 minutes or so; I'll try to run it under slime when I get a chance. The backtrace just shows that it's repeatedly trying to signal an error and getting an error while doing so; it's hard to know what the real problem is. 02:12:58 gbyers: Are you saying it IS failing in command line too? 02:13:08 No, I'm not. 02:13:48 I could not get it to repeat in command line, just running swank (some multi-thread thing?) 02:14:07 It's just sitting there in its loop, and will presumably do so until it runs out of memory or tries to make a very large bignum. 02:14:30 gbyers: I can give you access to a VM I have it failing on if you like 02:15:47 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [] 02:16:19 I have VMs; I don't have a lot of free time at the moment, though. The backtrace in your bug report just shows a lot of recursive errors, and I don't know what the original problem was. I'll try to run it under slime when I get some time, thanks. 02:16:42 gbyers: Fair enough. Thanks. 02:26:32 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl 02:36:29 gbyers: For what it's worth, it's a straight-up threading related bug easily repeated by firing off a couple of threads that perform the loop - from command line. I updated 571. . . . . 02:38:12 Well, that'll make it easier to look into when I get some time, thanks. 02:39:32 -!- gbyers [n=gbyers@c-68-35-15-143.hsd1.nm.comcast.net] has left #ccl 02:50:47 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl 05:23:51 -!- ChanServ [ChanServ@services.] has quit [simmons.freenode.net irc.freenode.net] 05:28:20 ChanServ [ChanServ@services.] has joined #ccl 05:28:20 -!- irc.freenode.net has set mode +o ChanServ 10:25:04 -!- ChanServ [ChanServ@services.] has quit [simmons.freenode.net irc.freenode.net] 10:37:59 ChanServ [ChanServ@services.] has joined #ccl 10:37:59 -!- irc.freenode.net has set mode +o ChanServ 12:30:06 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [] 13:01:13 sellout [n=greg@guest-fw.dc4.itasoftware.com] has joined #ccl 14:08:16 anRch [n=markmill@nmd.sbx07269.sauguma.wayport.net] has joined #ccl 14:10:54 segv [n=mb@p4FC1B4BD.dip.t-dialin.net] has joined #ccl 14:18:22 milanj [n=milan@93.87.169.228] has joined #ccl 14:37:37 -!- sellout [n=greg@guest-fw.dc4.itasoftware.com] has quit [simmons.freenode.net irc.freenode.net] 14:37:37 -!- gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [simmons.freenode.net irc.freenode.net] 14:43:10 sellout [n=greg@guest-fw.dc4.itasoftware.com] has joined #ccl 14:43:10 gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #ccl 15:53:27 rme [n=rme@pool-70-105-112-40.chi.dsl-w.verizon.net] has joined #ccl 15:57:49 -!- anRch [n=markmill@nmd.sbx07269.sauguma.wayport.net] has quit [] 16:06:29 gbyers [n=gbyers@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 16:40:17 lisppaste5 [n=lisppast@common-lisp.net] has joined #ccl 17:24:29 REPLeffect [n=REPLeffe@69.54.115.254] has joined #ccl 17:26:20 -!- REPLeffect [n=REPLeffe@69.54.115.254] has left #ccl 17:26:25 anRch [n=markmill@12.147.116.230] has joined #ccl 18:31:15 -!- billstclair [n=billstcl@unaffiliated/billstclair] has quit [Read error: 145 (Connection timed out)] 18:32:22 billstclair [n=billstcl@dsl-67-158-165-20.taconic.net] has joined #ccl 18:34:58 -!- anRch [n=markmill@12.147.116.230] has quit [] 19:14:43 anRch [n=markmill@nmd.sbx07283.medfoma.wayport.net] has joined #ccl 19:37:59 -!- jauaor [n=araujo@gentoo/developer/araujo] has quit [] 19:55:21 -!- ChanServ [ChanServ@services.] has quit [simmons.freenode.net irc.freenode.net] 20:13:10 ChanServ [ChanServ@services.] has joined #ccl 20:13:10 -!- irc.freenode.net has set mode +o ChanServ 20:13:49 -!- sellout [n=greg@guest-fw.dc4.itasoftware.com] has quit [] 20:54:09 -!- anRch [n=markmill@nmd.sbx07283.medfoma.wayport.net] has quit [] 20:56:13 -!- alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [] 20:58:05 -!- billstclair [n=billstcl@unaffiliated/billstclair] has quit [Read error: 113 (No route to host)] 20:58:17 billstclair [n=billstcl@unaffiliated/billstclair] has joined #ccl 21:45:40 alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 22:24:39 gz: I tried to make myself useful chasing 571; but the final symptom is in some pretty lowlevel code. I'm not sure how much of the language would be available to me if I try to log what's going on. One thing would be to embed data on the call stack - is there a way I can stop it from inlining functions like add-bignums? 22:27:44 You can't undo that in code that's already been compiled. When you're compiling code, declare notinline will do it. 22:34:32 gz: Yeah, I'm doing little mods to the code and recompiling it. 22:37:53 Have you tried having it loop doing something else? Isolate whether it actually has to do with bignums or if that's incidental. 22:38:30 -!- milanj [n=milan@93.87.169.228] has quit ["Leaving"] 22:40:55 gz: I have but have not been able to repeat the problem with anything else, including doing the same increment of a bignum over and over (a recreated bignum that is) 22:41:34 How about (loop (cons nil nil))? 22:42:47 If you mean (loop for if from 1 do (cons nil nil) . . . same 22:43:33 I mean without the 'i', so no bignum stuff. 22:47:59 Yeah, it grenades on (loop while (cons nil nil) do (cons nil nil)) 22:48:14 But I can't see a call stack for that 22:48:17 (with :B) 22:49:44 Well, it sounds like memory getting clobbered somewhere or something like that. Looks like gbyers will have to take a look at it. 22:50:59 You know what the weird thing is? It fails on simeltaneous allocation in the loop - but only if it's before the "do" 22:51:17 I.e. the only reason it isn't instant whith the bignums as that doesn't allocate until the higher numbers. 23:05:34 (loop for i from 1 to 2 do (process-run-function "test" (lambda nil (tagbody start (if (cons nil nil) 69 nil) (go start))))) <-- Only if there's the If and a non-NIL clause. Way over my head now. 23:53:43 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl