01:23:09 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 01:32:27 -!- milanj [~milanj_@178-223-163-100.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 04:06:52 attila_lendvai [~attila_le@37.99.49.125] has joined #sbcl 04:06:52 -!- attila_lendvai [~attila_le@37.99.49.125] has quit [Changing host] 04:06:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:07:41 pkhuong, what hack is that? 04:10:31 homie`` [~levgue@xdsl-87-79-193-141.netcologne.de] has joined #sbcl 04:12:13 -!- wbooze [~wbooze@xdsl-78-35-154-85.netcologne.de] has quit [Ping timeout: 245 seconds] 04:13:40 -!- homie` [~levgue@xdsl-78-35-154-85.netcologne.de] has quit [Ping timeout: 248 seconds] 05:08:19 -!- homie`` [~levgue@xdsl-87-79-193-141.netcologne.de] has quit [Ping timeout: 246 seconds] 05:54:36 sdemarre [~serge@91.176.179.236] has joined #sbcl 07:09:27 edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 07:09:55 ok, sbcl release attempt weekend 07:10:01 what total gotchas are still lurking? 08:22:28 homie [~levgue@xdsl-87-79-193-141.netcologne.de] has joined #sbcl 08:22:43 wbooze [~wbooze@xdsl-87-79-193-141.netcologne.de] has joined #sbcl 08:47:01 -!- cracauer [cracauer@nat/google/x-zmxksrqvzuejmjbo] has quit [Ping timeout: 246 seconds] 08:47:01 cracauer [cracauer@nat/google/session] has joined #sbcl 08:47:02 -!- cracauer [cracauer@nat/google/session] has quit [Changing host] 08:47:02 cracauer [cracauer@nat/google/x-qmvdpucxapklstws] has joined #sbcl 09:09:43 <_8david`> who cares? it's just another release. :-) 10:21:17 that's true 10:21:30 and I can always blame jsnell anyway 10:21:50 "it will take time for the new administration to resolve all the problems that it inherited" 10:21:56 *Krystof* looks forward to his politics career 11:06:42 <_8david`> This is a highly secret plan, and only for the ears of the very small, private circle of trusted individuals here :-), but: 11:07:07 <_8david`> I'm thinking about launching a separate line of SBCL releases, possible called SBCL-MTS, meaning "medium-term support". Think Ubuntu LTS, but considerably less long-term than that; hence medium-term. 11:08:47 <_8david`> The first SBCL-MTS would be merely a copy of some regular SBCL release tarball. But the promise (or idea at least) would be that bug fixes for SBCL-MTS do not appear only in the _next_ release (as in SBCL's regular snapshot-based release approach), but rather that important fixes would be backported as needed, and possibly released as easy-to-install fasl patches. 11:10:25 <_8david`> So anyone who feels that upstream SBCL is doing quit->exit style changes too aggressively, or that important bugs do not receive enough attention, might be more happy with that special release. A new version would appear (maybe) once or twice a year, but really depending on "when it's done", and not based on time-boxing. 11:11:32 <_8david`> And obviously, in order to nominate a bug fix for such backporting, the persons (or likely rather, companies) who desire such support get to pay a one-time or regular fee to me (or rather, my employer)... 11:12:42 <_8david`> So, there it is. I'm mentioning it here (long before actually doing or announcing it for the public), just so that anyone with objections (or indeed, interest in joining up to help) can think on this for a while and let me know. 11:24:38 H4ns [hans@netzhansa.com] has joined #sbcl 11:24:53 Process inferior-lisp trace/BPT trap: 5 on osx 10.8.2 - any ideas? 11:29:13 *_8david`* <- not a Mac OS expert 11:29:29 <_8david`> But still... so many questions... Which version of SBCL? Occasional bug or reliably broken? Only in SLIME or also outside of slime? Any debugging output prior to the crash? 11:29:42 it seems to be related to loading a shared library loading problem through uffi 11:30:01 always happens, on latest sbcl (from github.com:sbcl/sbcl master) 11:30:14 i'm working on nailing it down. 11:30:32 i also see sb-concurrency tests fail for 1.0.5[678] and master 11:30:43 <_8david`> okay, reproducability is the first step 11:31:41 <_8david`> Barring any other insight, I'd then compile with :ud2-breakpoints on *features* and attach gdb prior to the crash. That should give some more information. 11:32:54 <_8david`> (Because if you don't have :ud2-breakpoints, SIGTRAP happens all over the place for harmless reasons, rendering them undebuggable. But with :ud2-breakpoints, gdb should only show the one undesirable SIGTRAP.) 11:33:25 ok, so the problem occurs within (sb-alien:load-shared-object #P"/Users/hans/quickhoney/libs/cl-gd/cl-gd-glue.dylib") 11:35:45 <_8david`> I think the one big question our minds is: Do we have a regression relative to the previous SBCL release (which would hold up SBCL 1.1), or is it "just" an existing bug? 11:36:12 let me first try 1.0.56 with this same isolated test case 11:36:33 <_8david`> Aside from that, we'd also of course like to help you fix your problem :-), but I nominate one of the Mac OS users for that. 11:38:17 <_8david`> Personally I'm unfortunately busy keeping track of Linux/ppc, Linux/x86, Linux/x86-64, Solaris/sparc, Solaris/x86, WINE/x86 and Vista/x86 here. Mac OS X: Not in the picture yet for me... 11:38:40 uh. interesting. the crash happens only in slime. 11:41:02 <_8david`> H4ns: found it (maybe). https://bugs.launchpad.net/sbcl/+bug/592425 11:42:05 uh, nice. i'll try cyrus' suggestion 11:42:27 <_8david`> or avoid doing the load-shared-object in *slime-repl*, do it in *inferior-lisp* or .sbclrc instead. 11:43:09 hm. slightly inconvenient, but maybe that's the best thing to do. 11:46:53 pretty. loading from *inferior-lisp* solves the issue for me. i commented in the launchpad ticket the the problem occurred again. 11:47:24 <_8david`> OK. And what does output/building-contrib.sb-concurrency say regarding that problem? (With master.) 11:48:27 hold on. 11:49:02 mach_port_allocate_name failed with return_code 5 11:49:46 i've seen gary byers complain about and hacking on things related to mach_port_.* recently, might be similar to what he had to fix. 11:51:15 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 11:56:14 <_8david`> H4ns: hrm, we're already doing something _similar_ to clozure (yet slightly different). 11:57:26 <_8david`> SBCL 1.0.58 was the first release to fix the problem with Mac OS 10.8, but I don't know whether it is truly known or was only presumed to support 10.8.2. 11:57:36 <_8david`> pkhuong: ? 11:58:34 <_8david`> Last I heard was: yeah, we have the same issue. although our fix uses only one lowmem word per thread descriptor, so it isn't as bad. 12:00:05 did you see a launchpad issue on the topic yet? 12:04:53 found one. 12:04:58 https://bugs.launchpad.net/sbcl/+bug/1012811 12:06:32 <_8david`> maybe; I don't understand/recall this well enough to whether that is the 10.8.2 or the 10.8 issue. I think it's the latter, which has been fixed, not the former, which is new, and was presumed to not affect us too much. 12:06:51 <_8david`> Can you open a new ticket, just in case pkhuong and slyrus don't jump in and fix it within minutes :-)? 12:06:57 sure. 12:11:02 uh, it seems to be unrelated, i was looking at a 1.0.56 log before. 12:11:09 Fault @ 0x1008682020, page 4304 not marked as write-protected: 12:11:16 new ticket it is. 12:14:15 https://bugs.launchpad.net/sbcl/+bug/1058588 12:18:13 <_8david`> Reliable enough to allow bisection? 12:26:59 <|3b|> hmm, Invalid exit status: threads.impure.lisp 12:30:06 <_8david`> |3b|: gah! 12:30:10 <_8david`> Mr. Release Manager -- please take over. 12:30:23 *_8david`* <- afk for a birthday 12:30:51 <_8david`> |3b|: but in any case, what does the test output say exactly? 12:32:11 <|3b|> which test output? there didn't seem to be anything more useful in scrollback, and that was all it said about that file in summary 12:33:10 <_8david`> well, if in doubt, the entire .log from "run-tests.sh 2>&1 | tee .log" 12:33:28 <|3b|> that assumes it is repeatable, which it seems to not be so far :/ 12:33:48 *|3b|* wonders if test harness should save a log automatically or something 12:33:59 <_8david`> OK, in that case better just "run-tests.sh threads.impure.lisp 2>&1" until it fails again. 12:34:12 <|3b|> yeah, that was the plan 12:34:17 <_8david`> while run-tests.sh threads.impure.lisp >.log 2>&1; do : ; done 12:38:48 I'm also afk for a birthday! 12:54:14 -!- wbooze [~wbooze@xdsl-87-79-193-141.netcologne.de] has quit [Quit: none] 13:22:24 -!- homie [~levgue@xdsl-87-79-193-141.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:23:19 homie [~levgue@xdsl-87-79-193-141.netcologne.de] has joined #sbcl 13:23:23 wbooze [~wbooze@xdsl-87-79-193-141.netcologne.de] has joined #sbcl 13:44:02 the gencgc failure on darwin is almost reassuring; I have the same issue with soft warite barriers. 13:44:05 *write 14:55:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:00:31 <|3b|> seems to be :condition-variable :notify-multiple 15:02:01 <|3b|> got it stopping twice between printing 'condition-wait ' 1..10 and (condition-broadcast queue) 15:38:01 <|3b|> also seem to have a few "fatal error encountered in SBCL pid 3408(tid 140737333556992): 15:38:02 <|3b|> deferrables blocked" 15:38:50 <|3b|> around (:INTERRUPT-THREAD :DEFERRABLES-UNBLOCKED-BY-LOCK) 15:43:19 <_8david`> the last time we discussed the latter one we determined that the SLEEP just isn't sufficiently long 15:43:52 <_8david`> it's a bit suspicious, of course, that people didn't usually have this race, and now several people are reporting it 15:45:00 <_8david`> it's pretty dumb that this test, when it fails, aborts the whole file though. 15:47:48 <_8david`> no matter how suspicious, though, my suggestion would be to worry more about sb-concurrency and considerably less about :deferrables-unblocked-by-lock 16:04:51 <|3b|> and that time :spinlock-api apparently got a memory-fault error at address 1024 16:07:06 <|3b|> oops, (:TWO-THREADS-RUNNING-GC) not spinlockapi 16:08:39 <|3b|> http://paste.lisp.org/+2TZ8 16:16:32 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 16:17:12 <_8david`> if that is not caused by after-effects of previous tests, it's pretty scary, because :TWO-THREADS-RUNNING-GC is basically the big, trivial SBCL threading test #1. (And #2 would be two threads running GC -- but triggered implicitly, which is much more interesting.) 16:26:06 is there an easy way how i can install the sb-concurrency contrib despite the failing test? 16:26:21 <_8david`> touch contrib/sb-concurrency/test-passed 16:26:47 _8david`: thanks! 16:27:18 *Krystof* cries 16:27:45 Krystof: i'm just a user. 16:28:43 well, my cry is for want of a stress-free release weekend 16:28:50 clearly not going to happen 16:30:41 <_8david`> You can always claim that you only wanted to follow Nikodemus' suggestion to have two weeks of testing. A delay was part of the plan all along! 16:32:36 *|3b|* also got a run where it apparently forgot how to compile LET, but i assumed that was due to me messing with one of the other tests (not sure exactly how though) 16:33:17 -!- wbooze [~wbooze@xdsl-87-79-193-141.netcologne.de] has quit [Ping timeout: 246 seconds] 16:33:49 -!- homie [~levgue@xdsl-87-79-193-141.netcologne.de] has quit [Ping timeout: 246 seconds] 16:35:55 yeah. Maybe I can just blame everyone else's computer 16:36:12 I haven't yet tried on mine, so I'll continue to blithely assume that everything will work fine for me 16:37:17 woha, for some reason, 1.0.58 is considerably faster than previous versions with my application. congratulations! reads 70k records per second from postgres. 16:40:57 must be because we broke concurrency :-) 16:41:09 well done! :) 16:45:56 leuler [~user@p548FB882.dip.t-dialin.net] has joined #sbcl 16:49:40 I got this "Invalid exit status: threads.impure.lisp", too, when testing. Only once so far, not reproducible within a few attempts. That was an x86 build under x86-64/Linux. 16:52:05 <|3b|> yeah, pretty rare here, running x8664 on linux 16:59:54 <|3b|> another fatal error on deferrables-unblocked-by-lock 17:11:12 <|3b|> and another of those 17:16:25 Krystof: For the release, if your part in it encompasses building binaries, will the ones on Linux be linked against glibc 2.13 again? (lp#915171)? I am asking because a fellow lisper over here thought that upgrading libc on a customer's system was his best bet, when trying to get a recent binary version of SBCL to work, which (obviously) didn't work out too well. 17:22:05 <|3b|> ok, repeated GC crash outside tests, address 0 this time 17:50:55 <|3b|> 3 deferrables blocked in a row on another machine 17:56:16 gabnet [~gabnet@ACaen-257-1-23-41.w86-220.abo.wanadoo.fr] has joined #sbcl 18:02:57 *|3b|* supposes 'gc crash' isn't quite accurate, since the thread that apparently gets the memory fault isn't running GCs, and the other thread keeps going 18:03:28 <|3b|> and given it hasn't happened again, it could be rare enough to have been there indefinitely 18:05:56 <|3b|> and naturally when i say that it happens again :p 18:27:13 -!- Mazingaro [~Tetsuja@host110-237-dynamic.20-87-r.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds] 18:27:57 -!- gabnet [~gabnet@ACaen-257-1-23-41.w86-220.abo.wanadoo.fr] has quit [Quit: Quitte] 18:40:12 Mazingaro [~Tetsuja@host45-237-dynamic.6-87-r.retail.telecomitalia.it] has joined #sbcl 18:54:58 wbooze [~wbooze@xdsl-84-44-211-239.netcologne.de] has joined #sbcl 18:56:25 homie [~levgue@xdsl-84-44-211-239.netcologne.de] has joined #sbcl 19:14:05 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:24:58 leuler: I can try to link against an earlier version. Is there a simple way of doing that on a system with 2.13 installed, or do I need to construct a system with an earlier libc? 19:25:10 honestly, my chosen solution to his is not to produce binaries at all 19:26:46 Krystof: 2.13 is the desired one. Did you intend to write 2.14? 19:28:33 oh, right, I have 2.13 here 19:29:13 Krystof: I don't know of a simple way to link against a version different from the one the system uses, and it is not advisable to try to up- or downgrade libc. 19:29:24 the general question remains, though -- if I have a 2.x system, can I generate binaries that will at least start... ok 19:29:47 well, I'm less scared about upgrading libc on debian; I don't remember it ever making my system unusable 19:31:38 *|3b|* suspects building on debian stable would tend to link against something old enough for most people 19:32:45 there is that 19:32:56 I could set up a stable chroot 19:33:05 in a world where I have infinite spare time :-( 19:33:31 Krystof: Well, I remember having read scary things about what one needs to take into account to make a different libc version work. If you have already done such a thing your experience trumps whatever I have read. 19:34:18 Why the question about 2.x. Do you intend to change the system on which you build in the near future? 19:35:02 I run debian testing on my main computer 19:35:18 at the moment I run an old set of packages because I am too scared of gnome3 to do an upgrade 19:35:37 but at some point something shiny will exert its pull, and that will end up pulling in a newer glibc 19:35:51 as I say, I have no fear of that :) except that it will change my installed libc version 19:38:08 debootstrap is quite easy, btw 19:39:00 (unless my memory is mercifully suppressing some unpleasant details from a couple of years ago which was when I last used it, which it well might) 19:40:46 it is. The problem is the network bandwidth 19:40:54 I am at the end of a wet noodle here 19:41:05 I guess I can try it overnight 19:43:38 or since it is fairly minimal, maybe even my wet noodle can cope 19:49:13 <|3b|> 1.0.58.55 and 1.0.58.45 both have the memory-fault while doing lots of gc and starting threads problem, 1.0.32.something hasn't so far, building 1.0.58 to try, any other particular versions that might be interesting to test? 19:50:04 |3b|: try the ones around the commit that disentangle page size and card size, and the other that played with batched deallocation 19:50:13 (should be in the same ~week) 19:50:56 <|3b|> around late 1.0.49? 19:51:26 9effe671fd4baacd924b58a25dac89587d38eb27 19:52:37 <|3b|> ok, 1.0.58 died quickly 19:56:32 <|3b|> pkhuong: is that before or after the changes? 19:56:54 that's the first in that batch of changes. 19:57:02 <|3b|> ok 19:57:49 until ~26cad2d1328901538c3b57f6571321df4cad90e1 20:06:37 attila_lendvai [~attila_le@37.99.49.125] has joined #sbcl 20:06:38 -!- attila_lendvai [~attila_le@37.99.49.125] has quit [Changing host] 20:06:38 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 20:11:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 20:11:56 -!- edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: supernova explosion] 20:35:17 <|3b|> pkhuong: nothing so far from 9effe67 or 1.0.50 20:39:34 <|3b|> .57 breaks 20:40:18 weh ? 20:40:32 cps processing ? or why did 1.0.58 die ? 20:41:04 <|3b|> see logs... some very rare failure on one of the tests, trying to isolate it 20:47:25 *|3b|* wonders if the (:condition-variable :notify-multiple) problem is somehow related to the deferrables blocked problem... commented out :deferrables-unblocked-by-lock and :notify-multiple hasn't failed since 20:53:18 <|3b|> .55 and .56 seem OK so far 21:08:03 -!- sdemarre [~serge@91.176.179.236] has quit [Ping timeout: 245 seconds] 21:20:40 *|3b|* wonders if the test harness is killing the thread in :deferrables-unblocked-by-lock at a bad time 21:20:58 seems plausible. 21:23:36 <|3b|> currently looks like between 4ce962e and 3356431 for gc/threads thing 21:38:59 <|3b|> and bad at ef61e6, so seems to be the exit redesign 21:42:24 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 260 seconds] 21:46:03 <|3b|> yeah, seems to start at 1.0.56.55-f0da2f6 21:57:04 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 22:05:29 <|3b|> reported as https://bugs.launchpad.net/sbcl/+bug/1058799 22:08:31 *|3b|* wonders if it is also a problem that there are no restarts when that lands in the debugger 22:09:45 <|3b|> or that (exit) or (quit) don't work in that case 22:11:32 -!- _8david` [~user@port-92-195-118-78.dynamic.qsc.de] has quit [Ping timeout: 252 seconds] 23:00:33 -!- leuler [~user@p548FB882.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:12:45 -!- Phoodus [~foo@wsip-68-107-217-139.ph.ph.cox.net] has quit [Ping timeout: 256 seconds]