00:14:41 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 00:53:34 rbarraud__ [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 00:56:42 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 01:31:06 -!- rbarraud__ [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 01:42:13 -!- nyef [~nyef@pool-70-20-56-192.man.east.myfairpoint.net] has quit [Ping timeout: 245 seconds] 01:51:46 cmpitg [~cmpitg@118.71.132.157] has joined #sbcl 01:58:26 rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 03:26:33 -!- cmpitg [~cmpitg@118.71.132.157] has quit [Quit: leaving] 03:45:50 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 04:08:58 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 252 seconds] 04:33:11 -!- rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 276 seconds] 04:44:59 FareWell [~Fare@64.119.159.126] has joined #sbcl 05:00:23 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 05:00:57 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 06:04:46 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 06:05:04 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 06:11:28 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:34:47 -!- FareWell [~Fare@64.119.159.126] has quit [Quit: Leaving] 07:14:36 Blkt [~user@93-33-136-247.ip44.fastwebnet.it] has joined #sbcl 07:25:39 good morning everyone 07:32:37 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 07:32:37 -!- ChanServ has set mode +o nikodemus 07:39:38 good morning 07:59:02 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 08:11:45 Krystof [~csr21@158.223.161.73] has joined #sbcl 08:11:45 -!- ChanServ has set mode +o Krystof 08:11:49 cmpitg [~cmpitg@118.71.132.157] has joined #sbcl 08:17:48 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 08:40:45 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 08:47:00 -!- cmpitg [~cmpitg@118.71.132.157] has quit [Quit: leaving] 08:50:34 -!- Krystof [~csr21@158.223.161.73] has quit [Read error: Operation timed out] 08:57:30 Krystof [~csr21@158.223.161.73] has joined #sbcl 08:57:30 -!- ChanServ has set mode +o Krystof 09:07:27 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:35:42 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 10:24:42 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 10:32:22 minion: memo for nyef: in case you're curious, the junk in the component resulted from find-reference-funs expecting both halves of a tl-xep to be marked as having external refs 10:32:23 Remembered. I'll tell nyef when he/she/it next speaks. 10:34:31 rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 10:39:57 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 10:45:31 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 252 seconds] 10:54:26 Krystof [~csr21@158.223.161.73] has joined #sbcl 10:54:26 -!- ChanServ has set mode +o Krystof 11:04:05 -!- rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 11:04:28 rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 11:12:44 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 11:15:05 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 11:16:48 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 11:19:36 -!- rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 252 seconds] 11:32:22 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 11:46:17 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 12:00:34 nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has joined #sbcl 12:05:16 -!- nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has quit [Client Quit] 12:05:35 nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has joined #sbcl 12:06:06 G'morning all. 12:06:06 nyef, memo from nikodemus: in case you're curious, the junk in the component resulted from find-reference-funs expecting both halves of a tl-xep to be marked as having external refs 12:16:19 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 12:16:19 -!- ChanServ has set mode +o nikodemus 12:16:51 Hello nikodemus. 12:26:00 hi 12:26:55 I'm looking at bug 309098. Is the problem that the union is of array types and includes (ARRAY T)? 12:29:36 Ah, I see. The problem is that it's an exhaustive partition of the actual array element types. 12:30:05 As you were, then. 12:46:27 hmp. it looks like the 2% code bloat my patch introduces is legitimate 12:56:48 -!- nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has quit [Ping timeout: 245 seconds] 12:57:13 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 245 seconds] 13:01:02 :( 13:01:29 nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has joined #sbcl 13:01:48 My computer locked up solid. :-( 13:03:44 Nothing in the saved kernel log, either. :-/ 13:05:18 Krystof [~csr21@158.223.161.73] has joined #sbcl 13:05:18 -!- ChanServ has set mode +o Krystof 13:06:23 we don't have the ability to do fixups for inline constants, do we? 13:08:48 ... No, but we have the ability to have the ability. 13:09:12 ooo...meta 13:09:23 (Having just recently added a fixup-flavor, I know how it's done.) 13:10:40 it'd be nice to 1) have an inline constant for the address of an assembly routine that we call; and 2) ditto for alien functions, perhaps limited to functions in the runtime 13:10:42 What are the criteria SBCL uses to decide whether or not to inline a maybe-inline? 13:11:18 (I'm thinking x86-64 here) 13:11:41 Umm... Aren't these /already/ inline constants on x86-64? 13:12:00 so instead of lea eax, addr / call [rax] over and over, you just have call [rip+offset] 13:12:08 Ah! 13:12:36 Okay, that rather changes my interpretation of what you're after. 13:13:20 it also would require MORE DISASSEMBLER CLEVERNESS etc. 13:13:47 Not particularly much more, I wouldn't think. 13:14:53 tcr: just the optimization policy. e.g. (> speed space) 13:15:13 no, not a lot 13:17:57 we already have the fixup flavors; I guess we need some way of applying those to the inline constants 13:18:25 Right, and you can't quite do that with a back-patch. 13:19:24 ... You /can/ do it with the existing FOPs, though, I think. 13:20:11 And, bonus, it'll work for genesis as well if that's the case. 13:20:45 FOPs as in fasl ops? wouldn't that disallow this trick for in-core code? 13:21:37 Why would it? 13:22:16 um. 13:24:59 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:25:06 FOPs are not an in-core thing, are they? 13:25:47 Okay, I mostly see how to do this. 13:27:59 Anyway, in-core stuff is almost easier to deal with than in-fasl stuff. 13:35:39 ok, let's see if i can shrink the code legitimately... 13:36:04 froydnj: 32-bit or 64-bit values? 13:36:59 *nyef* is thinking 64-bit, but there's a complication in that case. 13:38:24 nyef: I don't think you can say CALL DWORD [RIP+offset], so they'd have to be 64-bit 13:40:03 Yeah, but it suddenly occurred to me that I can work around the damage by emitting a 32-bit fixup and some padding. 13:40:18 eeevil 13:42:23 rangerpb [~baude@gentoo/developer/rangerpb] has joined #sbcl 13:42:34 anyone built sbcl on sles11? 13:43:11 do you have problems? 13:43:37 yeah, on powerpc sles 11 13:44:20 What's "sles 11", specifically? 13:44:38 suse linux enterprise something? 13:44:43 Ah. 13:44:48 something like so: 13:44:49 http://pastebin.com/Zr5A3rf6 13:44:55 enterprise server, even 13:45:02 u0007121@172_29_149_204:~/lisp-suse/sbcl-1.0.43> cat /etc/SuSE-release 13:45:02 SUSE Linux Enterprise Server 11 (ppc64) 13:45:02 VERSION = 11 13:45:02 PATCHLEVEL = 1 13:45:20 yeah, had a customer request for a Common LISP on powerpc 13:45:27 was told to look at sbcl 13:45:41 built on RHEL5 on powerpc like a charm 13:45:45 ... 64-bit userland? 13:45:52 capable of both 13:45:54 unfortunately, sbcl doesn't support ppc64 (ppc32 only) 13:46:05 the kernel is 64 bit, the userland can be either 13:46:19 so you could build a ppc32 sbcl (may be slightly tricky), but native 64-bit is out 13:46:28 Right, I've got a 64-bit kernel and a primarily 32-bit userland here, with multilib (debian). 13:46:48 I occasionally toy with the idea of producing a ppc64 SBCL, though. 13:47:03 have fun with lowtags 13:47:20 ... What's the matter with lowtags? 13:48:13 *nyef* sighs. 13:48:26 I guess you could keep the lowtag scheme. but the reg+immoffset addressing mode on 64-bit memory insns only supports word (4-byte) offsets, not byte ones 13:48:30 so fellas, you think it might have detected 64bit capability and tried to build it as such? 13:48:30 Okay, where's a fixup that can be profitably registered this way that I can redefine at runtime? 13:49:28 rangerpb: I think cc on that system defaults to building 64bit programs, and you need to find some equivalent to CFLAGS=-m32 and possibly patch it into src/runtime/Config.ppc-linux 13:49:39 I guess you could look to ccl for inspiration; maybe they made lowtag-0 fixnums work on ppc64 13:49:42 yeah I think I can force that with linux32 /bin/bash 13:50:27 Okay, so try running linux32 ./make.sh ...? 13:50:31 retrying with that in mind 13:50:43 nyef, basically yes 13:50:59 btw, are there rpm specs for sbcl anywhere? 13:52:14 Hrm... Can't tweak the stuff in assembly/x86-64/support.lisp at runtime... 13:52:44 the way I compile 32 bit sbcls on 64 bit userlands is to have a directory with cc/gcc wrapper scripts that just add a -m32, and then PATH=../wrapper-dir:$PATH make.sh 13:52:45 dang, the linux32 option failed to build as well 13:53:35 http://paste.lisp.org/display/115268 # not a total loss performance wise :) 13:53:45 since we have places where CFLAGS isn't passed through properly (contrib builds, tests) 13:54:13 wow, what dropped FRPOLY and complex-methods? 13:55:33 also, STRING-CONCAT execution time is way out of line with everything else :) 13:56:11 running raw cl-bench is so 2002 :-D 13:56:23 froydnj: annotated 13:57:05 i keep wanting to write a new set of microbenchmarks and put it in sbcl cvs 13:58:58 minion: paste 115270? 13:58:59 Paste number 115270: "For froydnj: inline-constant fixups" by nyef in None. http://paste.lisp.org/display/115270 13:59:43 -!- froydnj [~froydnj@gateway.codesourcery.com] has quit [Ping timeout: 245 seconds] 13:59:52 froydnj: I'll let you take it from there. Enj... Hey! Get back here! 14:01:41 nyef, , "/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/bin/ld: powerpc:common architecture of input file `ppc-linux-os.o' is incompatible with powerpc:common64 output 14:01:41 " that tells me that the m32 in cflags for Config.ppc-linux isnt quite enuff (though it did appear to go further) 14:01:45 minion: memo for froydnj: inline-constant fixups: http://paste.lisp.org/display/115270 14:01:45 Remembered. I'll tell froydnj when he/she/it next speaks. 14:02:05 rangerpb: Add it to LDFLAGS as well? 14:02:26 ldflags in that same file or elsewhere? 14:02:36 Same place. 14:02:40 there aren't any 14:02:46 ok to add I assume? 14:03:04 Might be some in another Config.* file to use as a template. 14:03:24 yes, ok to add 14:04:09 I see some of the other 64 archs have -export-dynamic 14:04:33 the makefile also uses LINKFLAGS 14:04:49 I added LDFLAGS += -m32 14:04:54 that what you had in mind? 14:07:43 hmm, that didnt do the trick 14:10:05 As in, didn't appear in the invocation of the linker, or didn't affect the linker the way you wanted it to? 14:14:37 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:18:50 rangerpb: I think "-m32" is useless in LDFLAGS, it should be in CFLAGS instead. 14:21:00 ASau: The issue is that the linker doesn't believe the same set of flags. 14:21:25 nyef: this may be hard then. 14:21:48 SBCL build system doesn't follow standards. 14:23:57 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 14:57:54 hm. core bloat down to 1.7% by policy tweaks in the build and adding my trap-coalesing patch to the mix 14:58:22 *nikodemus* checks core size with mclim 15:02:26 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 264 seconds] 15:03:22 clim.core grows by 2.1% :/ 15:10:18 tcr1 [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 15:10:18 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 15:17:52 so one other question, does anyone have a SPEC file for sbcl? it would appear that would be difficult so i thought I would ask 15:19:25 I'm sure there must be one in fedora 15:20:28 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 15:20:28 -!- tcr1 [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 15:24:03 Krystof [~csr21@158.223.161.73] has joined #sbcl 15:24:10 -!- ChanServ has set mode +o Krystof 15:24:56 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Read error: Connection reset by peer] 15:25:27 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 15:29:15 rmarynch [~roman@88.135.194.233] has joined #sbcl 15:30:31 nyef: when do you plan to merge the disassembler stuff? 15:30:54 Umm... Not sure. 15:31:24 I guess some of it could go nowish, although I'm aware of at least one (duplicated) nasty hack, and there's still a bug with the type-tag stuff. 15:31:49 Do you want me to commit it sooner rather than later? 15:32:15 at least the symbol stuff would be nice to have sooner than later 15:32:28 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 15:32:31 i keep forgetting to build with it :) 15:32:48 Heh. 15:32:58 I'll put it on my list for this week, then. 15:33:03 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 15:33:03 thanks 15:33:37 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 15:36:34 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 272 seconds] 15:42:17 down to 1.98%... 15:42:59 Krystof [~csr21@158.223.161.73] has joined #sbcl 15:42:59 -!- ChanServ has set mode +o Krystof 15:51:16 *nyef* builds an x86 SBCL to test for a bug that he's fairly sure he fixed more than seven months ago. 15:54:01 I'm using (or (gethash ) (setf (gethash ))) all the time, I wonder if it warrants an optimization transformation, and if so how you'd actually do it 15:54:48 and for aref, or is it currently done already? 15:55:16 nope, but i like the idea 15:55:43 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 252 seconds] 15:56:02 I'll file a ticket 15:56:08 tcr: Sounds like something one would do with GET-SETF-EXPANSION. 15:57:44 nyef: doesn't have enough context 15:58:09 Really? 15:58:11 Hunh. 15:58:26 Why wouldn't it have enough context? 15:58:41 it doesn't see the OR for one thing 15:59:01 (LET ((#:G (FOO X))) (IF #:G #:G (SET-FOO X Y))) is the general pattern 15:59:13 Umm... No, I mean at the call-site. 15:59:36 i don't understand 15:59:59 Oh. The setf-expansion is bloody useless anyway. :-/ 16:00:28 i was thinking you would want to recognize those, and then have a way of asking for a combined accessor for FOO and SET-FOO 16:00:49 and probably generalize to tests beyond NIL too 16:01:03 and you'll need to make sure there are no calls in between which may modify the hashtable 16:01:04 Yeah, but the thing is, that's the sort of thing that belongs in the setf-expander. 16:01:28 That's what the general mechanism is there for. 16:01:57 for tricksy optimizations? :P 16:02:29 Precisely! 16:03:18 i think this only makes sense for builtin CL accessors: any user-level accessors can define their own ENSURE-FOO version, but recognizing the idiomatic pattern for common cases would be neat 16:08:23 isn't there already a "last-slot" optimization in the hash tables for exactly that case? 16:11:13 hash-tables, yes. but doing the same for arrays seems interesting 16:11:37 Krystof [~csr21@158.223.161.73] has joined #sbcl 16:11:37 -!- ChanServ has set mode +o Krystof 16:11:42 a single lockless cmpxchg would do it, me thinks 16:12:06 https://bugs.launchpad.net/sbcl/+bug/655816 16:12:08 Oh, a lockless version of compare-and-swap? 16:12:12 I often think that 16:12:12 what are we talking about? :-) 16:12:43 optimizing (or (aref v i) (setf (aref v i) x) 16:12:49 oo 16:13:07 also, if I'm reading the code correctly the cache doesn't seem to work for that case anyway 16:13:32 if with a cache, doesn't still calculate the hash twice, lock twice ? 16:15:17 wouldn't calculate the hash twice, and of course by default wouldn't do a lookup twice. and anyway it doesn't cache a failed lookup, so I was wrong originally 16:15:33 I guess the use case must have been (incf (gethash ...)) instead 16:41:11 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 276 seconds] 16:57:01 Krystof [~csr21@158.223.161.73] has joined #sbcl 16:57:01 -!- ChanServ has set mode +o Krystof 17:13:02 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 17:20:51 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 17:26:21 ; note: unable to optimize because: open coding coercion to LIST not implemented. 17:26:23 hah 17:46:59 -!- lnostdal [~quassel@167.80-203-136.nextgentel.com] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 17:48:46 lnostdal [~quassel@167.80-203-136.nextgentel.com] has joined #sbcl 18:01:49 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Disconnected by services] 18:01:49 attila_lendvai1 [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 18:01:49 -!- attila_lendvai1 is now known as attila_lendvai 18:02:27 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:09:22 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 252 seconds] 18:25:42 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 18:27:17 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 276 seconds] 18:30:22 I'm seeing a # {}> in the inspector 18:30:29 trying to inspect it results in a memory-fault 18:30:42 so I guess it's some random value interpreted as an lisp object? 18:33:14 hrm, it should either be NIL or a string 18:33:28 I wonder if that means that I somehow overwrote that memory address with junk 18:39:22 tcr: I blame bad type declarations, inherently unsafe operations, or a bogus dynamic-extent. 18:40:06 or messing with pointers :-) 18:40:37 That falls under "inherently unsafe operations". 18:41:40 fair enough 18:58:16 Hrrm.. the thing is I get memory faults after interactive development (C-c C-c here and there), but not when restarting, and reloading from scratch 18:58:25 so far anyway :-) 18:58:59 I'm using inline functions like hell 19:04:50 ... Doing any structure redefinition? 19:08:31 nope I don't think I did that the very last time 19:08:55 I think that structure redefinition was the thing that got me the most trouble in SBCL. 19:09:28 Well you will get lots of type errors of the form "The value #S is not of type FOO." :-) 19:09:48 Which is as magical as (defun car (x) (car x)) :-) 19:10:11 Yeah, except that I know how interpreter stubs work. 19:10:53 It's essentially the same thing thing I thought, some kind of an inlined layout check 19:15:15 slyrus [~chatzilla@dsl092-019-253.sfo1.dsl.speakeasy.net] has joined #sbcl 19:29:29 Krystof [~csr21@nat79.mia.three.co.uk] has joined #sbcl 19:29:29 -!- ChanServ has set mode +o Krystof 19:31:18 :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE 19:31:24 what was that one about again? 19:32:37 I'm using sb-kernel:system-area-ub8-copy to copy a dx C pointer to the heap; that's what it's supposed to do, isn't it? 19:34:29 I think it means it's stored in a register, but there's no interrupt context to read the register from. 19:37:05 Yeah, it's all register SCs. 19:38:01 What does that mean in simpler terms? 19:38:47 It means that the debugger has been told that the value is in a register, but it doesn't have the register contents available. 19:40:10 (Which is probably more a problem with the debug-info being dumped than anything else, since funcall requires spilling all register values back to the stack because there are no callee-saves registers in our calling convention. 20:00:16 Ugh. It's bloody difficult to get -anywhere- involving functions from the inspector. 20:00:40 I may end up defining some whateveritwas-PARTS methods at this rate. 20:04:22 ... "names an undefined function"? WTF? 20:31:21 How can I get the address of a struct slot? 20:33:10 I get a memory fault when trying to dereference a struct slot 20:35:31 -!- Krystof [~csr21@nat79.mia.three.co.uk] has quit [Ping timeout: 240 seconds] 20:35:52 Have a look in SRC:CODE;LATE-EXTENSIONS. 20:36:28 The atomic-incf and compare-and-swap stuff grubs through struct definitions to find slot indices. 20:37:21 http://paste.lisp.org/display/115287 20:37:53 PACKET.TCPH is the struct ref that somehow results in a crash 20:38:16 Previously it always crashed somewhere in printing, so I thought let's try SAP-INT on it 20:38:43 (PACKET.TCPH is declared to be of type SAP) 20:38:51 Hrm. 20:39:12 Can I find out more about that address where the memory fault happens? 20:39:15 Are you taking a SAP to a heap object outside of WITHOUT-GCING? 20:39:34 that sap comes from sb-kernel:system-area-ub8-copy 20:41:07 ... Comes from? 20:41:26 The declared type for system-area-ub8-copy returns (values &optional) 20:41:57 uh not for me 20:42:08 wait 20:42:30 right, it copies stuff from a dx C pointer into a foreign-alloc'd buffer 20:43:21 where cffi:foreign-alloc goes down to (alien-sap (make-alien uint8 size)) 20:44:05 Hrm. And where does the pointer come from? 20:44:14 the one that is copied? 20:44:17 Yeah. 20:44:36 from an mmapped filel :-) 20:45:46 Debugging at such a remove is hard. 20:45:57 remove? 20:46:15 Yeah, I'm nowhere near the code in question. 20:46:25 Or the problem, for that matter. 20:47:11 Wait, you just said (SAP-INT #xSOMETHING), and it blew up? 20:47:26 ShereKahn [~ajourez@64.65-67-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 20:47:34 Oh. No, you called PACKET.TCPH first. 20:48:16 I want to get that slot's offset and the address of the thing I'm calling it on 20:48:30 so I can see if the memory-fault is on that address 20:48:49 which it should not because the backtrace shows an SAP-INT frame  20:49:05 But the SAP-INT call failed? 20:49:25 The SAP object pointer itself isn't valid. 20:49:26 well that's where we got the signal 20:49:50 it's in the [:EXTERNAL] 20:50:01 SAP-INT takes a pointer to a "SAP object", which itself has two slots, a header and a value. 20:50:22 It checks the header, and then loads and boxes the value. 20:50:27 That's -it-. 20:51:35 well but sap-int should work even on SAPs pointing to an inaccessible memory address, shouldn't it? 20:52:00 Yes, my point is that you don't have a SAP, you have a bogus pointer that you think is a SAP. 20:52:09 the thing is that the backtrace shows [:external], and the PACKET.TCP ref might be inlined  so couldn't it be the slot ref after all? 20:52:16 Or you've trashed your read-only space. 20:52:53 what's the latter about? 20:52:56 No, because the [:EXTERNAL] seems likely to mean that it died before the no-arg-parsing entry point, which is to say the type test. 20:53:15 Which would imply that your read-only space (where the bignum allocation routines are) is probably okay. 20:53:18 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 20:54:32 does a sap have a widetag or a normal tag? 20:54:47 I mean does the typecheck involve a memory reference? 20:55:53 Widetag #x46, I believe. 20:56:31 so it involved a ref, hm 20:57:20 ... Oh. Of all the bloody stupid... Why, why, why does SBCL have this insane habit of destroying the interrupt contexts for memory faults? 20:57:35 Your failing SAP is #x21005a8c597. 20:58:00 You will be unable to MAKE-LISP-OBJ that value, because it's not a valid object. 20:58:36 Err... 587, not 597. 21:01:04 let me try that 21:01:14 So, the result from PACKET.TCPH is not a valid lisp object. 21:01:20 ITYM 580 21:01:20 Did you say it was a struct accessor? 21:01:27 yes 21:01:31 587, because of the type tag. 21:02:06 ... 7? On a 64-bit target? 21:02:11 yes 64 21:02:20 so wait what should I call make-lisp-obj with? 21:02:50 it takes the value at the memory address, or the address itself? 21:03:07 Oh! My bad, 58F. I was looking at the disassembly on an x86 lisp. 21:03:41 You call it with the address of a boxed lisp object. 21:04:02 It still won't work, because the object isn't valid. We know that it's not valid, because there was a memory fault when trying to read its type tag. 21:05:33 It says "is not a valid argument to make-lisp-obj" :-) 21:05:38 Right. 21:06:27 Your structure object is corrupt, or you're pulling a corrupt value from your array, whatever it is. 21:06:53 the other slots seems to be fine 21:07:08 I will cheerfully blame stale fasls or something if necessary. 21:07:25 uh but how?? 21:08:22 If you redefined a structure and then didn't rebuild all dependent fasls, but did rebuild the fasl with the structure definition, then quit out and started a new session by loading fasls instead of recompiling all your fasls... 21:10:41 uh well that code path was exercised about a million times before the crash :-) 21:11:16 anyway thanks for your time! even learned a couple of things 21:16:26 rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 21:21:27 Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 21:22:13 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 21:31:14 -!- rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 21:37:46 -!- ShereKahn [~ajourez@64.65-67-87.adsl-dyn.isp.belgacom.be] has quit [Quit: This computer has gone to sleep] 21:46:36 -!- rangerpb [~baude@gentoo/developer/rangerpb] has quit [Quit: Leaving] 21:57:39 -!- Blkt [~user@93-33-136-247.ip44.fastwebnet.it] has quit [Quit: Error: do not makunbound t please!] 22:55:50 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 23:39:05 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 23:39:14 rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 23:43:26 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 255 seconds]