00:05:44 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [] 00:12:43 palter_ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 00:12:44 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [Read error: 104 (Connection reset by peer)] 00:12:47 -!- palter_ is now known as palter 00:28:37 -!- mdc_mobile [n=mdc_mobi@216.239.45.19] has quit [] 00:30:01 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl 00:42:53 Adlai` [n=adlai@unaffiliated/adlai] has joined #ccl 00:45:37 -!- Adlai [n=Adlai@unaffiliated/adlai] has quit [Nick collision from services.] 00:45:41 -!- Adlai` is now known as Adlai 03:56:08 ccl-logbot [n=ccl-logb@master.clozure.com] has joined #ccl 03:56:08 03:56:08 -!- names: ccl-logbot Adlai sellout palter lispm alms sykopomp bfulgham_ pem gbyers billstclair lisppaste5 mdc PuffTheMagic_ chandler gz bfulgham @ChanServ 04:21:38 ccl-logbot [n=ccl-logb@master.clozure.com] has joined #ccl 04:21:38 04:21:38 -!- names: ccl-logbot Adlai sellout palter lispm alms sykopomp bfulgham_ pem billstclair lisppaste5 mdc PuffTheMagic_ chandler gz bfulgham @ChanServ 04:25:59 gbyers [n=gb@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 05:46:04 Adlai` [n=adlai@unaffiliated/adlai] has joined #ccl 05:47:20 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Nick collision from services.] 05:47:22 -!- Adlai` is now known as Adlai 06:14:01 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 06:14:38 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 06:32:30 milanj [n=milan@93.87.150.237] has joined #ccl 06:35:02 -!- bfulgham_ [n=brent@adsl-69-234-133-58.dsl.irvnca.pacbell.net] has quit [] 07:26:47 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 07:27:01 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 08:24:13 lpolzer [n=lpolzer@88.73.203.95] has joined #ccl 09:22:28 mdc_mobile [n=mdc_mobi@ip67-152-80-226.z80-152-67.customer.algx.net] has joined #ccl 10:47:38 Pocket [n=pocket@p2064-ipbf3403hodogaya.kanagawa.ocn.ne.jp] has joined #ccl 10:47:54 Hello, 10:48:55 I use ClozureCL on Windows Vista 32bit. 10:49:18 Today I try to make stand-alone application on my program. 10:49:39 So, I read manual and make application like this: 10:52:48 (ccl:save-application "hello" :toplevel-function 'main) 10:53:34 main is just print "hello" on console. 10:54:13 joswig [n=joswig@e177125031.adsl.alicedsl.de] has joined #ccl 10:55:04 But when I execute program just print "Program too big to fit in memory". 10:55:52 Does anyone know how to solve it? 10:56:07 -!- joswig [n=joswig@e177125031.adsl.alicedsl.de] has quit [Remote closed the connection] 11:01:28 Pocket: try (ccl:save-application "hello" :toplevel-function 'main :prepend-kernel t) 11:03:15 -!- lispm [n=joswig@e177156105.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)] 11:05:24 I got an error Error: value NIL is not of the expected type REAL. 11:08:26 What happens when you just run (main) at the repl? 11:09:56 main is (defun main () (format t "hello")) 11:10:24 So print Hello and return NIL 11:14:45 I try to change main like this (defun main () (format t "Hello") 0) 11:15:06 But I got same Error.. 11:17:00 not sure what the problem is, this works for me :\ 11:17:02 (I'm on Linux, though) 11:17:40 Thank you Adlai. 11:18:55 Ok, I'll try to ask same question on windows users group. 11:19:18 Thank you bye. 11:19:22 I'm not sure that'd be much help. I think your best bet is sending a message to the openmcl-devel list 11:19:44 Ok I try it. 11:20:00 -!- Pocket [n=pocket@p2064-ipbf3403hodogaya.kanagawa.ocn.ne.jp] has quit ["Leaving..."] 11:54:09 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Read error: 104 (Connection reset by peer)] 11:54:55 Adlai [n=Adlai@unaffiliated/adlai] has joined #ccl 12:46:30 -!- Adlai [n=Adlai@unaffiliated/adlai] has quit [Remote closed the connection] 12:46:46 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 13:24:12 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 13:24:41 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 13:36:08 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 13:36:38 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 13:42:36 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 13:43:05 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 13:44:45 -!- milanj [n=milan@93.87.150.237] has quit [Read error: 110 (Connection timed out)] 13:45:26 anRch [n=markmill@nmd.sbx09269.readima.wayport.net] has joined #ccl 13:54:03 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 13:54:35 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 13:54:52 cvandusen [n=user@12.185.80.194] has joined #ccl 14:12:02 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 14:12:41 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 14:26:40 milanj [n=milan@93.87.152.33] has joined #ccl 14:30:02 -!- gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Read error: 60 (Operation timed out)] 14:41:06 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 14:41:42 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 15:09:02 -!- mdc_mobile [n=mdc_mobi@ip67-152-80-226.z80-152-67.customer.algx.net] has quit [] 15:11:28 -!- anRch [n=markmill@nmd.sbx09269.readima.wayport.net] has quit [] 15:20:44 -!- milanj [n=milan@93.87.152.33] has quit ["This computer has gone to sleep"] 15:31:45 anRch [n=markmill@nmd.sbx07812.woburma.wayport.net] has joined #ccl 15:36:32 milanj [n=milan@93.87.116.131] has joined #ccl 15:38:30 rme [n=rme@pool-70-105-92-209.chi.dsl-w.verizon.net] has joined #ccl 15:39:40 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 15:49:12 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 15:51:39 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Remote closed the connection] 15:52:10 Adlai [n=adlai@unaffiliated/adlai] has joined #ccl 16:18:20 gbyers, I'm in a gdb session now that's broken on handle_fault after having received signal 11 16:18:58 is there something special you need to know from this context? 16:23:11 gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #ccl 16:26:32 lpolzer: you could try "info threads" and maybe "thread apply all bt" to see if that gives you any clues. 16:29:22 thanks, rme. there are a lot of active threads (~20) since I don't know any other way to provoke the problem 16:29:30 most of them are in a syscall 16:29:48 2 are in altstack_signal_handler 16:30:05 1 is in _SPheap_rest_arg 16:30:17 another 2 are in _SPgvset 16:31:10 3 have an unknown location on top of the call stack 16:31:20 and one is in handle_fault, obviously. 16:32:36 not sure if this is any help 16:34:20 try doing p *xp->uc_mcontext (I think.) 16:35:13 this will print out the processor state. 16:35:37 if you look at the value of rip, that will be the address of the faulting instruction. 16:36:25 You can see what it is with x/i 1234 (where 1234 is whatever rip was) 16:41:28 it's pushl 0xe(%ebx) 16:41:35 and ebx is zero in the context 16:42:05 can I do anything to find out what function this instruction belongs to? 16:44:46 in the output of "info threads", one of the lines should show that the thread is stopped at address 1234. that's the faulting thread. 16:47:13 or as an alternative, do p tcr->native_thread_id. 16:47:33 that will be the LWP number in something like "thread 14 (Thread 0x40263950 (LWP 2681))" 16:48:15 then you can say "thread 14" (or whatever it is), and then "where" to get a backtrace. 16:49:27 how would the tcr method work? it points me at the thread that handled the fault.. 16:51:55 ah, tcr seems to be local to handle_fault, not thread global. 16:52:11 but it does point me at the thread that handled the exception. 16:52:36 Maybe I'm full of it. The idea is to find the thread that caused the exception. 16:53:05 we know that the faulting address is 1234, right? 16:53:15 I mean, the address of the faulting instruction is 1234. 16:53:29 -!- anRch [n=markmill@nmd.sbx07812.woburma.wayport.net] has quit [] 16:53:34 yes 16:54:03 it's 0x140941d7 16:54:05 so in the output of "thread apply all bt", which thread is stopped at 1234? 16:54:27 none is 16:54:45 but I see that address in the backtrace for the exception handler thread 16:55:02 unfortunately there's no symbol attached to it 16:55:06 #0 handle_fault (tcr=0xaa7b3a70, xp=0xaa7b2ca4, info=0xaa7b2c24, old_valence=0) at ../x86-exceptions.c:795 16:55:06 #1 0x08061922 in handle_exception (signum=11, info=0xaa7b2c24, context=0xaa7b2ca4, tcr=0xaa7b3a70, old_valence=0) 16:55:06 at ../x86-exceptions.c:1066 16:55:06 #2 0x08061e19 in signal_handler (signum=11, info=0xaa7b2c24, context=0xaa7b2ca4) at ../x86-exceptions.c:1301 16:55:06 #3 16:55:32 #4 0x140941d7 in ?? () 16:55:32 #5 0x00000000 in ?? () 16:56:34 is there a way to tell gdb to decrement addresses until it finds one that has a symbol attached to it? 17:03:43 Would you please paste the output of x/20i 0x140941d7 17:04:52 (gdb) x/20i 0x140941d7 17:04:52 0x140941d7: pushl 0xe(%ebx) 17:04:52 0x140941da: jmp 0x140942b5 17:04:52 0x140941df: mov -0x34(%ebp),%ebx 17:04:52 0x140941e2: mov %ebx,%eax 17:04:53 0x140941e4: and $0x7,%eax 17:04:57 0x140941e7: cmp $0x1,%eax 17:04:59 0x140941ea: jne 0x14094370 17:05:01 0x140941f0: pushl 0x3(%ebx) 17:05:03 0x140941f3: mov -0x38(%ebp),%ebx 17:05:05 0x140941f6: call *0x151b8(,%eiz,1) 17:05:07 0x140941fd: mov $0x140940c6,%edi 17:05:09 0x14094202: mov %ebx,%esi 17:05:11 0x14094204: mov -0x8(%ebp),%ebx 17:05:13 0x14094207: cmp %ebx,%esi 17:05:15 ---Type to continue, or q to quit--- 17:05:17 0x14094209: jne 0x140942a9 17:05:19 0x1409420f: push $0x0 17:05:21 0x14094211: jmp 0x14094285 17:05:23 0x14094213: mov -0x4(%ebp),%esi 17:05:27 0x14094216: mov -0x3c(%ebp),%ebx 17:05:29 0x14094219: nop 17:05:49 (lisppaste is in the channel, btw) 17:06:10 oh, yeah. 17:06:36 ok, that looks like lisp code. 0x140940c6 is the address of the lisp function. 17:07:21 great 17:08:07 if you loaded lisp-kernel/linuxx8632/.gdbinit, "pl 0x140940c6" should tell you what it is. 17:08:30 $7 = 0x80809a0 "#" 17:08:57 looks related to my problem with threads creating packages at runtime. 17:09:26 yes, seems so. 17:09:33 I guess the ccl kernel is looking at a half-done new package. 17:11:26 maybe package stuff isn't properly protected by locks? 17:20:40 If the hypothesis is that there's a thread-safety bug in the package code, maybe it would be possible to come up with a test case. Maybe a few threads creating, using, and deleting packages like crazy would provoke the bug. 17:22:48 I will try to prepare such a case 17:23:11 Thank you; that would really help. 17:23:16 in the meantime, thanks for the debugging help. 17:23:24 remote telepathic debugging only gets you so far 17:23:51 it's more than I expected 17:38:00 anRch [n=markmill@72.170.207.26] has joined #ccl 17:53:55 -!- anRch [n=markmill@72.170.207.26] has quit [] 18:49:41 -!- PuffTheMagic_ is now known as Stugots 18:59:56 lispm [n=joswig@e177125031.adsl.alicedsl.de] has joined #ccl 19:16:35 anRch [n=markmill@12.147.116.234] has joined #ccl 19:30:20 lpolzer pasted "Concurrent package operations" at http://paste.lisp.org/display/89318 19:30:38 this doesn't provoke the error we discussed 19:30:52 but I get 19:30:55 > Error: Fault during read of memory address #x-27DB3CDC 19:30:55 > While executing: DELETE-PACKAGE, in process creator(998). 19:31:08 you may need to run this a few times to get this error. 19:40:06 I can get the error. I will make a Trac ticket for this. At first glance, it looks like delete-package is (at least) neglecting to use the associated locks when reading/modifying the %all-packages% 19:47:29 http://trac.clozure.com/openmcl/ticket/616 20:00:39 lpolzer: I committed r13100 to the trunk; maybe that'll help. 20:01:02 you mean for the original problem? 20:01:21 it addresses your test case. 20:03:09 But if the %all-packages% list is screwed up or in some intermediate state, that could cause %find-pkg to malfunction as we saw. 20:03:38 ah, good point. 20:03:58 -!- anRch [n=markmill@12.147.116.234] has quit [] 20:05:05 (your test case has a race condition in it between the delete-package and make-package: some other thread could make a "FOO" package first.) 20:05:49 yes 20:06:31 I was too lazy to look up the names of ccl's locking functions... 20:09:26 I'll give the main app a run tomorrow, good night and thanks again. 20:10:07 thanks for spending some time on this bug. good night. 20:50:29 -!- lispm [n=joswig@e177125031.adsl.alicedsl.de] has quit [] 20:51:02 lispm [n=joswig@e177125031.adsl.alicedsl.de] has joined #ccl 21:39:16 -!- cvandusen [n=user@12.185.80.194] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 22:17:21 anRch [n=markmill@98.98.42.166] has joined #ccl 23:07:41 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 23:11:23 -!- anRch [n=markmill@98.98.42.166] has quit []