00:32:44 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 01:24:39 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 252 seconds] 01:29:45 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 01:35:39 plutoid [~pluto@218.206.101.179] has joined #sbcl 01:54:08 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 240 seconds] 02:01:40 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 02:30:23 attila_lendvai [~attila_le@87.247.60.50] has joined #sbcl 02:30:23 -!- attila_lendvai [~attila_le@87.247.60.50] has quit [Changing host] 02:30:23 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 02:58:04 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 244 seconds] 03:00:27 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 03:34:08 -!- plutoid [~pluto@218.206.101.179] has quit [Quit: Leaving] 04:51:47 homie [~levgue@xdsl-84-44-154-83.netcologne.de] has joined #sbcl 04:53:08 -!- saschakb [~saschakb@p4FEA1031.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:53:35 stassats [~stassats@wikipedia/stassats] has joined #sbcl 05:04:17 saschakb [~saschakb@p4FEA0477.dip0.t-ipconnect.de] has joined #sbcl 05:06:46 evening 05:08:18 morning 05:18:46 morning 05:34:46 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 05:49:48 -!- akovalenko [~akovalenk@95.73.125.83] has quit [Quit: rcirc on GNU Emacs 24.0.92.1] 05:51:18 akovalenko [~akovalenk@95.73.125.83] has joined #sbcl 05:59:53 nikodemus [~nikodemus@188-67-240-100.bb.dnainternet.fi] has joined #sbcl 05:59:53 -!- ChanServ has set mode +o nikodemus 06:08:43 morning 06:12:12 hey nikodemus, it's time for bed here, but have you looked at *code_vector in catch_exception_raise? 06:13:45 I'm curious if they're al EXC_I386_GPFLT or if the bogus mach exceptions are different 06:15:35 gnight 06:22:00 homie` [~levgue@xdsl-84-44-155-29.netcologne.de] has joined #sbcl 06:24:26 -!- homie [~levgue@xdsl-84-44-154-83.netcologne.de] has quit [Ping timeout: 252 seconds] 07:08:39 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 07:28:47 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 240 seconds] 07:32:03 sdemarre [~serge@91.176.187.36] has joined #sbcl 07:51:47 -!- sdemarre [~serge@91.176.187.36] has quit [Ping timeout: 240 seconds] 07:59:11 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 08:57:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 09:13:39 attila_lendvai [~attila_le@87.247.50.232] has joined #sbcl 09:13:39 -!- attila_lendvai [~attila_le@87.247.50.232] has quit [Changing host] 09:13:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:25:35 borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 09:26:15 Phoodus [~foo@68.107.217.139] has joined #sbcl 09:26:58 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 252 seconds] 09:33:16 -!- borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 252 seconds] 09:42:41 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 09:45:19 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 268 seconds] 11:09:32 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 11:12:31 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 244 seconds] 11:22:44 attila_lendvai [~attila_le@87.247.60.162] has joined #sbcl 11:22:44 -!- attila_lendvai [~attila_le@87.247.60.162] has quit [Changing host] 11:22:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:30:26 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 12:01:51 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 12:41:49 attila_lendvai [~attila_le@87.247.60.162] has joined #sbcl 12:41:49 -!- attila_lendvai [~attila_le@87.247.60.162] has quit [Changing host] 12:41:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:01:08 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 13:01:20 attila_lendvai [~attila_le@87.247.46.238] has joined #sbcl 13:01:20 -!- attila_lendvai [~attila_le@87.247.46.238] has quit [Changing host] 13:01:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:07:34 -!- saschakb [~saschakb@p4FEA0477.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 13:12:38 so, what to do with %report-reader-error modifying the stream index? 13:13:40 hargettp [~hargettp@96.237.120.39] has joined #sbcl 13:14:08 (https://bugs.launchpad.net/sbcl/+bug/902118 for context) 13:34:45 only use it for streams that are pathname designators, and open a new stream for the line & column calculation 13:35:19 what about just backing up? 13:36:20 i think making the error handler move the pointer is pretty icky 13:36:54 s/handler/printer/ 13:36:55 i can't decide what importance to assign to this bug, low or medium? 13:37:06 medium, i'd say 13:37:29 ok 13:37:33 it's user-observable, and i don't see an obvious workaround, and you don't have to do anything really exotic to run across it 13:38:15 especially since slime uses read-from-string 13:39:35 anyway, i won't be working on this bug right now, so if you want you may kill it 13:42:56 i have my plate full right now :) 14:00:33 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:00:41 G'morning all. 14:04:06 nikodemus: FOP-INTERN? Really? 14:05:24 And losing the record of what FOPs 6 and 7 were isn't cool, either. 14:06:39 nyef: are you disagreeing with the name or the refactoring? 14:06:55 The name. 14:07:04 ok 14:07:16 intern-for-fop? 14:07:22 If I see a function FOP-*, I expect it to be an actual FOP, and will tend to look for the FOP code. 14:07:25 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has left #sbcl 14:07:42 i'll change it 14:07:48 what value does knowing what fops 6 and 7 were have? 14:08:28 There might not be value, but the FASL format is fairly close to undocumented as it is. 14:09:01 leuler [~user@p54903AC0.dip.t-dialin.net] has joined #sbcl 14:09:21 There are several comments throughout fop.lisp showing what certain FOPs were throughout history. 14:11:20 true, but i don't think they actually make understanding it any easier -- quite the opposite 14:11:51 but i can restore the commend while fixing the name, it's not a biggie 14:12:42 i mainly deleted it as "this made sense when we were closer to cmucl so that divergences needed explanation" 14:13:08 I suppose anyone really curious could look through the history of fop.lisp in git. 14:20:05 while on the subject of fops: do you know while fop-uninterned-symbol-save and it's small version don't have the same +sb-xc-host conditionals as eg. fop-named-package-save? 14:20:38 No, I have no idea. 14:24:22 At some point I'd like to go in and refactor the entire FOP implementation. 14:24:51 Maybe get rid of the distinction between XC and target FASL string formats. 14:25:17 that would be nice 14:26:13 i've been thinking about looking at our fasls and seeing if we can speed up loading a bit by adding a few new fops specifically for things like common toplevel forms 14:26:36 obviously with the co-operation of fopcompile 14:27:53 How about dumping the strings all at once in in-memory format. Use WITHOUT-GCING, grab however many pages required, read directly from the disk into the memory pages, construct pointers to the strings, kick the GC back in. 14:30:36 would be good 14:31:27 Build is broken on cheneygc. 14:31:27 also: put all code objects in the same part of the fasl, mmap that, fixup as needed, tell the GC about it -- and let the gc unmap it when there are no more pointers to it 14:31:44 That was another option, yes. 14:31:48 crap 14:32:00 print.c includes gencgc-alloc-region.h 14:32:41 feh. complately forgot about that one 14:32:41 For that matter, the definition of alloc_region in thread.h looks shockingly bogus. 14:33:08 I'm going to try something fairly simple as a fix. 14:41:51 Does http://paste.lisp.org/display/126383 look good to you? 14:43:32 yeap 14:43:45 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 14:45:12 Okay, I'll put together a proper commit after this build. 14:58:17 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:11:17 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:30:19 antgreen [~user@70.50.67.239] has joined #sbcl 15:42:41 plutoid [~pluto@180.174.17.39] has joined #sbcl 15:43:27 ... what happened with bug 308926? 15:43:55 'cause if I fixed that, I'd like to understand how. 15:45:13 bisection in order, probably 15:45:38 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 15:46:37 Mmm. Maybe I'll do that later. 15:51:51 nikodemus: did you see my note about inspecting *code_vector in catch_exception_raise? 15:55:13 beslyrus: yes. it's always currently always NULL because we don't use catch_mach_exeception_raise, which would require adding MIG generated files to the tree... 15:55:42 i tried it, though, and the code vector looked just the same as always 15:55:53 hrm... OK. never mind then. 15:56:25 i think using vm_region is the next one that makes sense 15:58:56 -!- plutoid [~pluto@180.174.17.39] has quit [Quit: Leaving] 16:46:15 attila_lendvai [~attila_le@87.247.3.122] has joined #sbcl 16:46:15 -!- attila_lendvai [~attila_le@87.247.3.122] has quit [Changing host] 16:46:15 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:59:32 *|3b|* wonders if bug 330299 lost some characters somewhere or if i'm missing something 17:02:27 -!- akovalenko [~akovalenk@95.73.125.83] has quit [Ping timeout: 240 seconds] 17:03:38 akovalenko [~akovalenk@95.73.107.89] has joined #sbcl 17:03:40 *|3b|* also wonders why it is linked to some random mdadm.fixes tree 17:06:54 |3b|: i think it's missing a couple of \'s yeah 17:07:31 <|3b|> ah, bit-vector vs element-type bit, that would make sense then 17:09:43 i'm suddenly inclined to use the first element of a vector to hold an index into it instead of a vector with a fill pointer 17:30:07 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 18:29:50 milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has joined #sbcl 18:34:03 sdemarre [~serge@91.176.187.36] has joined #sbcl 18:38:29 saschakb [~saschakb@p4FEA09D5.dip0.t-ipconnect.de] has joined #sbcl 18:43:42 otter-gwc [~brianj@68.107.217.139] has joined #sbcl 18:44:57 Afternoon, everyone. I've got an sbcl crash reporting this out std.err (using the .54 sbcl release): GC invariant lost, file "thread.c", line 646 18:45:06 And then sbcl shuts down. 18:46:04 <|3b|> probably should specify os/cpu arch too 18:46:20 -!- hargettp [~hargettp@96.237.120.39] has quit [Quit: Linkinus - http://linkinus.com] 18:46:36 <|3b|> and for best results, what you were doing at the time 18:46:46 Good point: Linux CSCMS-SERVER-2 2.6.35-22-server #33-Ubuntu SMP Sun Sep 19 20:48:58 UTC 2010 x86_64 GNU/Linux 18:47:00 is it xen or something? 18:47:15 No, dedicated box. 24 cores, 24 GB ram. 18:47:37 And it's a server, I don't think anyone was on at the time. I got the error from the log. 18:47:50 But idle, the server still constantly cycles. 18:50:59 The same thing happened in the git head version before .54 was released, but this is the first time I've seen it since then. 18:51:05 Is that the one in create_os_thread(), protected by ifdef LOCK_CREATE_THREAD? 18:52:28 Also, we have sb-ext:bytes-consed-between-gcs set to 8GB. 18:53:40 And --dynamic-space-size 20gb 18:57:12 In gc_stop_the_world 19:00:25 It's not within the ifdef scope. So, this happens if a thread exits during the call it seems. 19:03:02 Too long since I've done pthreads. The thread wasn't found as living, but wasn't marked dead either, so the assert fails. 19:04:16 sbcl version? 19:04:23 -!- antgreen [~user@70.50.67.239] has quit [Remote host closed the connection] 19:04:58 Lisp is SBCL 1.0.54 19:14:10 hunh 19:14:34 i can't see a good reason for that to happen. 19:15:18 -!- stassats` [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:15:29 It only seems to hit on the production machine. I'm trying it on our large memory/fewer core in-house box now, but it happens rarely (but a few times/week so far) 19:15:38 It's never hit on our dev boxes. 19:16:10 unless it's a pthreads & signal handlers issue :/ 19:16:58 otter-gwc: i can make a patch that tries again a limited number of times, in case it is a transient issue 19:17:27 I'll certainly run it. Or, if it helps, make one that dumps to stderr any more useful data you'd like. 19:19:36 homie`` [~levgue@xdsl-78-35-182-234.netcologne.de] has joined #sbcl 19:20:01 "GC invariant lost" happens a lot if you have type errors. 19:20:08 (and you compile in safety 0) 19:21:08 dunno if that's the problem in your case, but it certainly happens to me a fair amount. :) 19:21:18 It sounds like a reasonable concern. 19:21:42 That one I'll pass to Phoodus to check ;) 19:21:53 -!- homie` [~levgue@xdsl-84-44-155-29.netcologne.de] has quit [Ping timeout: 240 seconds] 19:22:41 If that can cause it then the C code is probably fine. 19:23:27 We run a lot of memory; we sent the patch to increase the GC limits to 64 bit on 64 bit boxes for instance, so I worried that perhaps some aspect of large RAM caused it. 19:25:21 foom: pthread_kill returning ESRCH isn't likely to be caused by type-errors, though 19:26:13 nikodemus: yea...probably not. 19:27:34 otter-gwc: http://random-state.net/tmp/0001-try-to-handle-spurious-ESRCH-from-pthread_kill.patch 19:28:00 utterly untested, except that it seems to build with slam.sh fine 19:28:35 *otter-gwc* grins 19:28:42 How wrong could it be, after all, it compiles ;) 19:29:50 hm. i wonder if full signal queue could cause that too. 19:30:30 We tend to run about 40 threads (we use a thread pool, so we don't grow without bounds). 19:35:18 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Operation timed out] 19:39:21 *|3b|* runs into %vector-widetag-and-n-bits again, should really file a bug one of these days :p 19:44:04 -!- saschakb [~saschakb@p4FEA09D5.dip0.t-ipconnect.de] has quit [Quit: Verlassend] 19:45:24 *|3b|* wonders if ironclad makes that mistake anywhere else 19:50:23 -!- ljos [~mozzyb@login1.uib.no] has quit [Ping timeout: 252 seconds] 19:51:26 ... one of these days, I really need to sit down and work out why PPC blows up horribly in ROOM. 19:51:27 *|3b|* seems to have pretty old ironclad though, probably should fix that too 20:12:11 -!- nikodemus [~nikodemus@188-67-240-100.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 20:40:35 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 20:53:42 slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 20:53:48 -!- slyrus_ is now known as slyrus 20:58:12 nikodemus [~nikodemus@188-67-240-100.bb.dnainternet.fi] has joined #sbcl 20:58:12 -!- ChanServ has set mode +o nikodemus 20:59:16 *|3b|* wonders why sbcl would DX allocate 2 arrays of arbitrary size, but not 3 21:02:14 can i haz test caze/ 21:02:35 <|3b|> allocating the arrays you mean? 21:02:53 <|3b|> hmac.lisp in ironclad 21:03:14 <|3b|> after specifying a type for block-length 21:08:03 <|3b|> ah, looks like difference is initialized to 0 doesn't get DX, initialized to non-zero does 21:14:55 <|3b|> reduced: http://paste.lisp.org/display/126388 21:25:41 Is there any reason the GC would trigger before hitting the 8gb dirty limit we set in bytes-consed-between-gcs? 21:26:11 I see the memory going up from 1.2gb to 5.4 gb then re-setting to 1.2, so gc seems to be triggered. But there's no reason for it to be triggered with that small an amount 21:30:33 never mind -- gc threshold is 4 instead of 8 again for some reason 21:35:35 -!- sdemarre [~serge@91.176.187.36] has quit [Ping timeout: 240 seconds] 21:37:40 |3b|: thanks, logged https://bugs.launchpad.net/sbcl/+bug/902351 21:38:20 <|3b|> cool 22:02:44 slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 22:28:28 nikodemus: which commit fixed the clx issue? 22:29:17 the stack allocation compiler note error fixx 22:30:53 -!- ASau [~user@89-178-12-247.broadband.corbina.ru] has quit [Remote host closed the connection] 22:31:17 ASau [~user@93-80-101-77.broadband.corbina.ru] has joined #sbcl 22:38:39 ok, thanks! 22:39:49 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:44:18 |3b|: it seems to actually fails to stack allocate all but the zero-filled ones, but the deftransform for fill has a muffle-conditions declaration which hides that 22:44:18 oops 22:44:43 <|3b|> heh 22:46:48 pchrist_ [~spirit@gentoo/developer/pchrist] has joined #sbcl 22:49:08 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 252 seconds] 23:05:00 -!- pchrist_ [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 23:05:33 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 23:08:53 <|3b|> nikodemus: are those arrays expected to be stack allocatable if things were working properly? 23:13:53 |3b|: in theory, yes 23:14:11 but it's not obvious to me how to make it better in hurry 23:14:58 so i'm going to remove the muffling from FILL, comment on the bug, and leave it for later 23:16:08 <|3b|> ok 23:17:34 |3b|: :initial-element 0 -- or leaving it out entirely, and exlicitly calling FILL after they've been allocated in the body of the LET is the easy workaround 23:17:48 *|3b|* doesn't think it matters for what i'm doing with it anyway 23:31:23 -!- slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 252 seconds]