00:25:49 -!- edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: no future] 01:57:12 -!- wbooze [~wbooze@xdsl-78-35-161-134.netcologne.de] has quit [Ping timeout: 260 seconds] 02:13:48 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 03:14:17 -!- SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has quit [Quit: Lost terminal] 03:15:46 SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 03:43:06 -!- huangjs [~huangjs@69.84.244.131] has quit [Ping timeout: 240 seconds] 03:52:51 huangjs [~huangjs@69.84.244.131] has joined #sbcl 04:00:07 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: Ex-Chat] 04:53:07 Fare [~fare@p18229-ipngn100402kyoto.kyoto.ocn.ne.jp] has joined #sbcl 05:04:23 tcr [~tcr@1.211.55.74] has joined #sbcl 06:22:58 prxq [~mommer@mnhm-590c21d8.pool.mediaWays.net] has joined #sbcl 06:30:49 -!- antifuchs [~foobar@boots.boinkor.net] has quit [Ping timeout: 272 seconds] 06:33:02 antifuchs [~foobar@boots.boinkor.net] has joined #sbcl 06:41:47 jdz [~jdz@85.254.212.34] has joined #sbcl 06:50:02 -!- tcr [~tcr@1.211.55.74] has quit [Quit: Leaving.] 06:52:28 tcr [~tcr@1.211.55.74] has joined #sbcl 06:54:57 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 07:25:30 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:29:31 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:40:38 huangjs [~huangjs@69.84.244.131] has joined #sbcl 07:42:56 -!- Fare [~fare@p18229-ipngn100402kyoto.kyoto.ocn.ne.jp] has quit [Ping timeout: 246 seconds] 07:48:26 attila_lendvai [~attila_le@37.99.77.64] has joined #sbcl 07:48:26 -!- attila_lendvai [~attila_le@37.99.77.64] has quit [Changing host] 07:48:26 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:59:38 jdz [~jdz@85.254.212.34] has joined #sbcl 08:01:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 08:01:58 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:07:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 08:23:56 attila_lendvai [~attila_le@87.247.56.113] has joined #sbcl 08:23:56 -!- attila_lendvai [~attila_le@87.247.56.113] has quit [Changing host] 08:23:56 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:29:17 -!- huangjs [~huangjs@69.84.244.131] has quit [Ping timeout: 255 seconds] 08:30:35 huangjs [~huangjs@69.84.244.131] has joined #sbcl 08:43:15 -!- tcr [~tcr@1.211.55.74] has quit [Ping timeout: 260 seconds] 08:45:04 tcr [~tcr@1.211.55.74] has joined #sbcl 09:11:50 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 09:18:23 yena [~yena@akasha.ayai.com] has joined #sbcl 09:55:12 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:55:30 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:09:07 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 10:09:52 attila_lendvai [~attila_le@87.247.13.39] has joined #sbcl 10:09:52 -!- attila_lendvai [~attila_le@87.247.13.39] has quit [Changing host] 10:09:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:25:03 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:05:56 rpg_ [~rpg@216.243.156.16.real-time.com] has joined #sbcl 12:07:54 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Read error: Operation timed out] 12:20:59 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 12:23:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 14:09:43 wbooze [~wbooze@xdsl-84-44-208-138.netcologne.de] has joined #sbcl 14:11:40 -!- tcr [~tcr@1.211.55.74] has quit [Quit: Leaving.] 14:17:04 tcr [~tcr@1.211.55.74] has joined #sbcl 14:17:17 -!- tcr [~tcr@1.211.55.74] has quit [Client Quit] 14:21:37 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 14:22:13 -!- rpg_ [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 245 seconds] 14:23:35 Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has joined #sbcl 14:28:03 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 14:56:33 rpg [~rpg@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:12:24 -!- Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has quit [Ping timeout: 260 seconds] 15:25:29 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:31:35 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 246 seconds] 15:35:48 edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 15:56:26 -!- yena [~yena@akasha.ayai.com] has quit [Quit: yena] 15:56:54 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 16:25:47 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 17:07:31 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 246 seconds] 17:10:25 make-host-1.sh; make-target-1.sh; make-host-1a.sh; make-target-1a.sh; make-genesis-2.sh; make-target-2.sh; make-target-contrib.sh 17:10:33 Call me old-fashioned, but that doesn't seem optimal to me. If only because I'd have to memorize the new sequence. 17:19:03 nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has joined #sbcl 17:37:54 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: Ex-Chat] 17:38:28 -!- slyrus [~chatzilla@adsl-108-81-169-220.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 268 seconds] 17:41:53 huangjs [~huangjs@69.84.244.131] has joined #sbcl 17:48:59 We're in code freeze, aren't we? 17:49:32 I guess MAKE-OTHER-IMMEDIATE-TYPE gets a stay of execution until after the release. (-: 17:59:38 yena [~yena@akasha.ayai.com] has joined #sbcl 18:04:27 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 18:14:30 gko [~user@220.228.255.202] has joined #sbcl 18:16:20 Can anyone please explain why PROGV involves an UNWIND-PROTECT? 18:17:07 Specifically, an UNWIND-PROTECT that does an UNBIND-TO-HERE, when ANY NLX entry will do an UNDBIND-TO-HERE as a matter of course? 18:18:40 nyef: I'm equally surprised, sorry. 18:19:23 If I create a hash-table with :weakness :value, is it reasonably to expect that the data will stay as long as there's free (room)? 18:19:44 I think I have a line of argument that could require it, surrounding a non-local control transfer out of a PROGV but within the same function, so no actual NLE will be emitted. 18:19:55 flip214: No, it is not reasonable to expect that at all. 18:19:56 -!- gko [~user@220.228.255.202] has quit [Read error: Connection reset by peer] 18:19:56 I think that GC takes this data much to eager for my use-case ... I need some kind of cache 18:20:16 so, what's better then? 18:20:24 flip214: In fact, expect the GC to flush the values as soon as it can. 18:20:37 hmm, yes, that's what seems to happen. 18:20:40 flip214: the nice people on #Lisp may have already encountered this situation. 18:21:05 pkhuong: hello, and thanks once more for your help yesterday! 18:21:31 according to my copy of cltl2 :weakness seems to be an sbcl extension, that's why I'm asking here. 18:22:08 CLtL2 is not authoritative, but it is an implementation-specific extension, though hash-table weakness is fairly common. 18:22:57 we need a new lisp standard. 18:23:06 Let's not go there. 18:23:10 ;) 18:24:36 Okay, PROGV involves UNWIND-PROTECT. I don't have UNWIND-PROTECT yet, but I want to test that the rest of PROGV works, specifically UNBIND-TO-HERE... The only thing to do is to be lower-level with my test case. /-: 18:25:58 nyef: whatcha working on that doesn't have unwind-protect yet? 18:25:59 nyef: convert that uwp to a m-v-prog1? 18:26:17 foom: ARM. 18:26:48 pkhuong: Same problem, it's a necessary cleanup for certain cases of non-local control transfer. 18:27:21 I guess those cases don't apply to me yet, but I'd rather not hack up IR2TRAN any worse than I have already. 18:27:48 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 18:35:02 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has quit [Quit: Bye.] 18:36:08 I currently figure that getting all of the dynamic binding, NLX, error traps, P-A, heap allocation, and ALIEN-FUNCALL working would be a good enough start that other people could plausibly take a look. 18:47:24 (That's most of the basic structure of the backend, for the record. There'd still be quite a bit to do, but all of the bits that require deep knowledge of what's going on would be pretty much done.) 19:53:48 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 276 seconds] 20:07:36 -!- huangjs [~huangjs@69.84.244.131] has quit [Remote host closed the connection] 20:14:51 msmith1 [~msmit297@adsl-184-36-173-69.asm.bellsouth.net] has joined #sbcl 20:15:18 anyone notice sbcl.org is down? 20:16:07 msmith1: www.sbcl.org is not. 20:16:41 <|3b|> connection reset from www.sbcl.org here 20:16:55 down on both counts here. 20:17:55 looks like a general .sourceforge.net issue to me 20:17:58 <|3b|> probably sourceforge problems, connection reset from sbcl.git.sourceforge.net too 20:19:57 it's down for me too 20:27:08 Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has joined #sbcl 20:27:09 and here too. 20:27:24 -!- prxq [~mommer@mnhm-590c21d8.pool.mediaWays.net] has quit [Quit: Leaving] 20:37:57 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 20:48:18 udzinari [~udzinari@ip-89-102-31-29.net.upcbroadband.cz] has joined #sbcl 20:50:45 *lichtblau* doesn't understand how and where we're violating SEHOP rules 20:52:12 lichtblau: SEH issue? Are there multiple unwind blocks allocated in the same block (or function)? 20:52:38 we've never respected LIFO ordering for these. 20:53:45 I figured we could fix that as a post-pass in regalloc, but I think nyef had a better principled idea. 20:54:04 ... That's still a going concern? 20:54:48 I've had two or three stabs at that, but was never quite happy with any of them. 20:54:58 But I think the record of my attempts was on lisppaste. 20:55:35 uhm. I thought UWP only restores a previous SEH handler. 20:56:09 Installation of a handler happens during thread creation and call_into_lisp, I thought. 20:56:55 And SEHOP checks that the chain of `next' slots actually leads to an original handler somewhere in ntdll. AFAICT, we take care of chaining next correctly. 20:58:14 nyef once pointed me to an msdn entry that says the chained entries' addresses must be ordered correctly on the stack as well. 20:58:29 I don't remember that, but I do remember that they have to be. 20:58:52 And integrating SEH frames and catch blocks fixed a huge amount of graft-vs-host syndrome. 21:02:36 nyef: Please "Explain to me like I'm five" (as they say on the internet these days) -- why are we using nested SEH handlers at all? 21:04:13 Also in light of the fact that our amd64 port (well, Anton's amd64 port) doesn't do that sort of thing, and pretty much works fine. (Doesn't do it, presumaby, partly because amd64 SEH is table-based, and hence harder, of course. But still.) 21:06:10 Well: Not that it really helped to remove classic SEH either. I've built a binary which only uses one vectored exception handler (like we do on AMD64), and never touches %fs:0. 21:06:46 Vectored exception handlers were too new to use at the time, for starters. 21:06:50 While a normal binary never even gets the first wp violation, this modified binary reaches the exception handler once. But when that handler returns with exceptioncontinueexecution, the process seems dead in the water. 21:07:58 And when I tried to use a single SEH frame rather than integrating things, I had an awful amount of trouble getting a second exception rather than the process just getting killed. 21:09:56 I started trying to do something with two SEH frames in order to run the unwind, and that just got insane and never worked quite right. 21:10:41 At which point I decided to just stick an SEH frame in our catch blocks and use RtlUnwind, which basically got everything working. 21:10:55 see, that's my question. Why care about unwind? Anton's binary stopped caring about Unwind even on x86 a while ago, IIRC. 21:11:05 Except for this one minor case that still hasn't been fixed years later... 21:11:07 (I didn't merge that change.) 21:11:08 rpg_ [~rpg@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 21:11:08 -!- rpg_ [~rpg@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Client Quit] 21:11:25 For FFI integration purposes, primarily. 21:11:26 Well, maybe my focus ought to be on merging the amd64 port, not on porting 32bit SBCL to 64bit Windows with SEHOP enabled. But I predict that before the end of the year, gazillions of users will have a fancy new windows and complain that SBCL doesn't work. 21:13:12 (And "use regedit" is an answer, but not a good one.) 21:13:28 Dare I ask? 21:13:38 Ask what? :-) 21:13:50 What breaks, and why regedit fixes things? 21:14:39 ah. I'm on Server 2012, which has HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\DisableExceptionChainValidation set to 0, which means that SEHOP is enabled. 21:14:54 -!- rpg [~rpg@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 21:15:22 (Haven't checked yet whether Windows 8 comes with the same setting. It would have the same kernel, I think, but not necessarily the same defaults.) 21:17:25 Ah. Hunh. 21:18:16 So, the basic constraint is that the SEH frames need to be ordered in a particular way. 21:18:56 And there's no real controls on PACK to request a particular ordering. 21:19:09 But since they're PHYSENV-LIVE, once they're packed they're packed. 21:19:16 Well, this article: http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx says that the final next slot needs to be correct. 21:20:10 Because they're assuming that shell code authors overwrite %fs:0 without setting next correctly. (No idea why that would be so, but I'm sure someone thought it plausible.) 21:24:01 Anyway. All this really only to get myself a 64 bit windows, and I'm not still seeing the error Anton V. is reporting on sbcl-devel for the new release. 21:26:35 Hrm. 21:27:44 So, this shouldn't affect the most basic uses of SEH, only the cases that break already, right? 21:28:58 I guess the basic test would actually be to fire up a "working" SBCL and walk the SEH chain directly, printing the frame addresses. 21:59:55 0028f8f8[handle_exception_wrapper] -> 0028fef4[handle_exception_wrapper] -> 0028ffc4[ntdll!wcstol] -> ffffffff 22:00:34 (no, I don't believe the wcstol either) 22:01:23 That looks like a reasonable chain to me, other than the wcstol, and we're unlikely to have monkeyed with that. 22:10:45 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 22:15:00 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 252 seconds] 23:09:29 yena_ [~yena@cpe-72-177-30-155.austin.res.rr.com] has joined #sbcl 23:12:06 -!- yena [~yena@akasha.ayai.com] has quit [Ping timeout: 264 seconds] 23:12:06 -!- yena_ is now known as yena 23:18:26 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:23:59 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:30:52 -!- Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has quit [Quit: Leaving]