00:17:02 -!- milosn [~milosn@94.12.79.143] has quit [Ping timeout: 264 seconds] 00:20:46 crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl 00:35:19 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 00:35:34 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 00:49:29 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 01:18:17 -!- ASau` is now known as ASau 01:44:38 -!- joshe [~joshe@2001:470:e862::1:1] has quit [Ping timeout: 264 seconds] 02:12:25 milosn [~milosn@94.12.79.143] has joined #sbcl 02:16:49 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 02:31:00 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 02:46:46 prxq_ [~mommer@x2f6baf6.dyn.telefonica.de] has joined #sbcl 02:50:24 -!- prxq [~mommer@x2f69179.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 02:53:44 yacks [~py@103.6.159.103] has joined #sbcl 03:21:01 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 03:38:53 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 245 seconds] 03:39:41 -!- christoph_debian [~christoph@ppp-88-217-48-178.dynamic.mnet-online.de] has quit [Ping timeout: 272 seconds] 03:51:49 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 03:52:40 christoph_debian [~christoph@ppp-88-217-53-94.dynamic.mnet-online.de] has joined #sbcl 03:54:45 -!- loke_ [~loke@203.127.16.194] has quit [Ping timeout: 248 seconds] 03:56:18 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all] 04:06:10 loke_ [~loke@203.127.16.194] has joined #sbcl 04:13:21 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 04:35:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:12:14 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 06:12:41 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:12:48 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Remote host closed the connection] 07:09:46 Krystof [~user@81.174.155.115] has joined #sbcl 07:09:46 -!- ChanServ has set mode +o Krystof 07:18:27 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 265 seconds] 07:32:48 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 07:39:24 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Read error: Connection reset by peer] 08:02:52 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 08:11:08 -!- crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [Ping timeout: 265 seconds] 08:18:32 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 08:34:10 -!- Krystof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 09:36:47 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:44:47 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 09:47:32 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 10:30:58 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 10:31:21 wbooze [~wbooze@xdsl-78-35-161-65.netcologne.de] has joined #sbcl 10:35:59 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:36:07 two's complement for bignums makes things quite hard 10:37:33 maybe it simplifies some computation, i haven't checked, but the extra sign digits get in the way 10:41:14 -!- wbooze [~wbooze@xdsl-78-35-161-65.netcologne.de] has quit [Quit: Client Quit] 10:49:16 wbooze [~wbooze@xdsl-78-35-161-65.netcologne.de] has joined #sbcl 10:55:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:15:46 Krystof [~user@81.174.155.115] has joined #sbcl 11:15:46 -!- ChanServ has set mode +o Krystof 11:24:23 -!- wbooze [~wbooze@xdsl-78-35-161-65.netcologne.de] has quit [Ping timeout: 252 seconds] 11:25:50 -!- oleo [~oleo@xdsl-78-35-161-65.netcologne.de] has quit [Ping timeout: 245 seconds] 11:26:22 oleo [~oleo@xdsl-78-35-134-233.netcologne.de] has joined #sbcl 11:30:08 wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has joined #sbcl 11:31:00 -!- wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has quit [Client Quit] 11:32:30 helps bitwise and short (2 word) bignums 11:38:03 wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has joined #sbcl 11:46:27 -!- wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has quit [Quit: none] 11:53:22 wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has joined #sbcl 12:07:02 i would settle for the complement but without the sign bit 12:30:13 -!- wbooze [~wbooze@xdsl-78-35-134-233.netcologne.de] has quit [Quit: none] 12:56:24 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 13:01:03 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 13:06:59 -!- milosn [~milosn@94.12.79.143] has quit [Ping timeout: 240 seconds] 13:09:11 milosn [~milosn@94.12.79.143] has joined #sbcl 13:30:08 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 13:48:17 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 14:01:10 LiamH [~none@96.231.217.60] has joined #sbcl 14:08:14 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:48:54 segv- [~mb@95-91-241-45-dynip.superkabel.de] has joined #sbcl 15:09:09 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 15:29:19 attila_lendvai [~attila_le@5.76.185.228] has joined #sbcl 15:29:19 -!- attila_lendvai [~attila_le@5.76.185.228] has quit [Changing host] 15:29:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:29:50 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 15:42:31 leuler [~user@p548F98CD.dip0.t-ipconnect.de] has joined #sbcl 15:47:32 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 15:49:37 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 16:29:26 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 16:32:55 crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl 17:25:37 nyef [~nyef@pool-64-222-145-64.man.east.myfairpoint.net] has joined #sbcl 17:25:46 Hello all. 17:26:16 I'm continuing bisecting the sparc build failure, but at this point it looks as though it's likely to be a lifetime issue somewhere. 17:26:58 doesn't the same fix as ppc work? 17:27:40 No, but that will probably be necessary as well. 17:29:35 Explicit birth/death annotations within VOPs would be nice, because we could use them to cross-check, at runtime, that the overall lifetime information (used by PACK) is correct. 17:39:43 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 260 seconds] 18:10:21 crixxus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl 18:11:29 SPARC MOVE-COMPLEX-SINGLE-FLOAT-ARG VOP looks wrong, but not dangerously so. 18:11:45 it's unlikely to be invoked during the build 18:11:51 True. 18:12:49 MOVE-COMPLEX-DOUBLE-FLOAT-ARG, same thing. 18:13:08 And LONG-FLOAT-ARG, same thing, but even less likely to be a problem. 18:13:23 <|3b|> did anyone have any thoughts on http://paste.lisp.org/+30TF ? 18:13:26 -!- crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [Ping timeout: 272 seconds] 18:14:14 |3b|: It's not at all familiar to me, I'm afraid. 18:14:45 *|3b|* mostly wonders if there is any extra info i should try to extract from it before filing a bug 18:15:17 <|3b|> though just poking around in the backtrace ended me up in the debugger again 18:16:23 There's a relevant sbcl-devel thread, apparently. 18:16:50 http://thread.gmane.org/gmane.lisp.steel-bank.devel/10175 18:18:04 How easy is it for you to reproduce this? 18:18:11 *|3b|* suspects not at all 18:18:24 Hrm. 18:18:30 <|3b|> i couldn't even recompile iolib when i started a new sbcl after that 18:18:55 I'm not sure what I can tell you, then. 18:19:07 <|3b|> ok 18:19:32 Probably should report it, just in case anyone has any ideas, plus it'll remind people that the issue is still there. 18:19:40 <|3b|> hmm, maybe spamming cffi:foreign-type-size in a loop while compiling things would reproduce it 18:20:12 <|3b|> since it seems to have been that rather than the opencl itself 18:20:27 *|3b|* should probably figure out how to avoid doing that at runtime in the opencl lib though 18:22:04 The non-V9 versions of ABS/DOUBLE-FLOAT and %NEGATE/DOUBLE-FLOAT worry me slightly. 18:22:32 (x and y can overlap, and there's an fmovs instruction to move bits around that would move one register to itself.) 18:23:22 crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl 18:23:25 <|3b|> yep, that hit it almost instantly 18:23:51 If you've got an easy way to reproduce it, it's DEFINITELY worth reporting. 18:24:03 *|3b|* suspects it happens when it tries to load the .fasl 18:25:13 <|3b|> and seems to persist once it happens 18:25:33 <|3b|> ok, bug report time 18:29:11 <|3b|> hmm, not doing it now :/ 18:31:44 <|3b|> got it again, just loading .fasls from a different project, so at least it isn't compilation or iolib specific 18:33:23 <|3b|> and one of the threads got a failed aver instead that time 18:34:00 <|3b|> or 2 of them 18:36:29 -!- crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [Ping timeout: 240 seconds] 18:36:50 -!- crixxus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [Ping timeout: 264 seconds] 18:39:01 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 18:44:52 i can reproduce it too 18:45:31 <|3b|> probably helps if i don't reduce it to something checkable at compile time :p 18:46:05 *|3b|* reduced it to an index out bounds in classoid-typep 18:49:05 <|3b|> possibly related to typep with classes with 2 superclass with a common superclass 18:49:28 http://paste.lisp.org/display/141027#1 18:50:13 <|3b|> yeah, that looks better than my test case 18:51:25 does it work for you? 18:51:43 <|3b|> yeah, getting same errors 19:01:55 <|3b|> is there any way to tell sbcl debugger toprint the error again? 19:02:08 <|3b|> ah, i guess "error" 19:02:43 erro.. yes 19:16:16 so, typep is run after the layout is invalidated by setting invalid to T, but before it's set to (:obsolete something) 19:18:33 and it's under a word lock, that's why there's no progress and infinite recursion 19:18:54 <|3b|> https://bugs.launchpad.net/sbcl/+bug/1272742 19:19:18 <|3b|> failing to get the index out of bounds again though, should have saved that backtrace 19:28:22 the combination of %update-slots and make-instance-obsolete seems suspect 19:28:23 <|3b|> ok, got the index out of bounds again from my ugly test case... happens in %puthash in %ensure-classoid-valid 19:28:39 <|3b|> does that sound like a different bug? 19:28:53 <|3b|> %ensure-classoid-valid was called fro classoid-typep 19:31:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:41:42 there's an old bug somewhere with a patch about that 19:42:32 <|3b|> looks like that is due to it using a hash table that isn't synchronized-p 19:43:08 <|3b|> since the hash table is big enough by the time the debugger sees it 19:44:03 <|3b|> or not enough locking somewhere else i guess 19:44:56 <|3b|> looks like sb-pcl::*previous-nwrappers* is the hash table 19:47:44 looks the original problem is lying with it too 19:49:31 <|3b|> the hash table? 19:50:14 yeah, with how it's maintained 19:50:22 the values in it 19:52:07 it grows a large list of (:obsolete the-same-wrapper) for some reason 19:53:22 but it doesn't need to be synchronized, since it's protected by the world-lock 19:53:50 at least it has to be protected 19:54:12 <|3b|> well, when i get index out of bounds, all the threads get it 19:54:28 <|3b|> so it gets unprotected at some point 19:54:54 <|3b|> doesn't help that half the call stack is tail-called out on the way to the %puthash though 19:56:57 <|3b|> not seeing any world lock on this backtrace 19:57:08 there's something weird going on with *previous-nwrappers*, that's for sure 19:58:37 <|3b|> typep -> %typep -> %%typep -> classoid-typep -> %ensure-classoid-valid -> %force-cache-flushes -> %invalidate-wrapper -> (setf (gethash nwrapper *previous-nwrappers*)) 20:00:43 yeah, looks like it doesn't have a word-lock 20:02:42 classoid-typep advises against a world lock... 20:03:11 not sure if %ensure-classoid-valid could use the lock despite that advice 20:03:42 (aver (< i 2)) fails because of that too 20:05:28 <|3b|> hmm, maybe it could at least error instead of risking corrupting things if something else has the lock and it wants to make changes? 20:05:44 *|3b|* isn't sure that is actually better or not 20:07:24 <|3b|> is having its own lock bad? 20:07:58 for the *previous-nwrappers*? probably not, but that doesn't solve the recursion problem 20:08:19 <|3b|> i meant %ensure-classoid-valid or somewhere higher than the hash table itself 20:08:34 <|3b|> wherever it starts modifying things 20:09:36 <|3b|> or at least global things 20:11:11 *|3b|* 's test case had typep on a class that wasn't being modified, which seems a bit worse than problems when the class is actively being redefined 20:12:01 pnpuff [~harmonic@unaffiliated/pnpuff] has joined #sbcl 20:22:14 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 20:26:38 SPARC bisection continues, but we're down to just the PACK stuff, which strongly indicates a VOP lifetime problem somewhere. /-: 20:26:50 -!- pnpuff [~harmonic@unaffiliated/pnpuff] has quit [Read error: Connection reset by peer] 20:30:05 world-lock in %force-cache-flushes seems to do the job 20:30:52 <|3b|> cool 20:30:54 i think the describe problem with world-lock is when there's an while it is held, then slime has a trouble working to display that error 20:30:59 described 20:31:12 there's an error 20:31:48 ensure-classoid-valid signals such errors 20:34:20 *|3b|* added the stuff about the hash table to the error, since they seem to have same root cause 20:37:29 i'll commit the world-lock wrapping after the freeze 20:39:25 (< (aver i 2)) is sufficiently annoying 20:39:50 maybe i need to look why the world lock is causing a deadlock in that place and fix it that way 20:41:59 -!- fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has quit [Ping timeout: 240 seconds] 20:46:08 can an instance typep with an obsolete layout? 20:46:37 if somebody is so eager to redefine classes during code execution, then he won't mind a wrong answer to TYPEP 20:46:49 fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has joined #sbcl 20:47:09 since even the right answer can become wrong after typep finishes, world lock or not 20:47:35 How wrong is a wrong answer? 20:47:36 so, i say, try for invalidness one time, and just proceed checking the type, valid the layout or not 20:48:27 nyef: wrongly returning (typep x 'class) => T for a class redefined during the execution of typep 20:48:31 *|3b|* 's test cases were breaking on a class that wasn't being redefined, more reasonable to break on a class that is redefined (as long as it doesn't break anything else) 20:49:06 if the code looks like (when (typep x 'class) (class-slot x)) is still broken, since the redefinition can come between the test an the call to class-slot 20:49:25 <|3b|> yeah, but " 20:49:39 <|3b|> "don't do that" is more reasonable for redefining a class in a loop while using it 20:49:53 did your test case break on (aver (< i 2))? 20:49:56 <|3b|> compared to saying "don't load any code while doing a typep" 20:50:03 <|3b|> yeah, all 3 errors 20:50:10 <|3b|> on my test case at least 20:50:27 and you were not redefining any of its type hierarchies at any time? 20:50:27 <|3b|> only got the cache flush from "real" use 20:50:40 <|3b|> let me just add it to the bug 20:51:23 Is this wrongly returning true from typep because it WAS true before the redefinition? 20:51:36 yes 20:51:48 Okay, I don't have a problem with such a race condition. 20:52:29 So long as the cache is reasonably coherent on both sides of the operation. 20:53:22 slapping a world-lock around (typep x 'class) just won't solve the fundamental problem with such redefinitions, just push it away 20:54:01 and most of the time type-hierarchy doesn't change radically enough for typep to changes its answer 20:54:57 so, it would do the right thing more often then a failing AVER 20:55:13 <|3b|> ok, updated 20:58:26 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 20:58:34 can't seem to be able to reproduce with the world-lock around %force-cache-flushes, trying again 20:58:39 then will trying without the lock 21:00:37 can't reproduce either way 21:02:54 <|3b|> yeah, takes a few tries with mine 21:03:25 and i don't really see how it would be triggered without redefinitions 21:03:37 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 21:05:11 but it manages to overheat my cpu, i need a better cooler 21:05:28 <|3b|> oops, guess i missed pasting the definition of *stop* 21:08:04 <|3b|> hmm, not crashing now 21:13:25 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 21:18:24 <|3b|> running in a loop, and not crashing... i wonder what i did differently 21:19:26 *|3b|* wonders if slime affects it too 21:27:25 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 21:37:54 -!- prxq_ is now known as prxq 22:23:49 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 22:24:05 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 22:26:49 I'm on the last build of the bisection, and it's definitely something to do with the PACK changes. 22:57:19 Hrm. SPARC MAKE-COMPLEX-SINGLE-FLOAT can probably be improved with a little work, but doesn't seem to be broken. 23:20:21 And I've just realized that I have a way to try and determine what VOPs are broken for this particular failure mode. 23:21:01 I "just" need to get traces covering the three or four most relevant functions in the backtrace, then see if the assembly code makes sense. 23:21:30 And bisect blames 4ba392170e98744f0ef0b8e08a5d42b988f1d0c9 which affects PACK behavior. 23:28:39 Nothing looks too broken in compiler/sparc/float.lisp, either... Doesn't mean that the issue isn't there, just means that if it is there then it's subtle. 23:42:55 -!- oleo [~oleo@xdsl-78-35-134-233.netcologne.de] has quit [Ping timeout: 245 seconds] 23:43:24 oleo [~oleo@xdsl-78-35-161-165.netcologne.de] has joined #sbcl 23:51:56 -!- leuler [~user@p548F98CD.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:56:17 ASau` [~user@p54AFE507.dip0.t-ipconnect.de] has joined #sbcl