2014-11-01T00:19:24Z attila_lendvai quit (Quit: Leaving.)
2014-11-01T01:20:26Z leo2007 quit (Quit: rcirc on GNU Emacs 25.0.50.9)
2014-11-01T01:48:18Z edgar-rft joined #sbcl
2014-11-01T02:31:43Z karswell quit (Read error: Connection reset by peer)
2014-11-01T02:33:28Z karswell joined #sbcl
2014-11-01T02:38:47Z karswell quit (Read error: Connection reset by peer)
2014-11-01T02:39:24Z karswell joined #sbcl
2014-11-01T03:39:17Z christoph_debian quit (Ping timeout: 260 seconds)
2014-11-01T03:52:20Z christoph_debian joined #sbcl
2014-11-01T04:21:53Z asedeno quit (Ping timeout: 272 seconds)
2014-11-01T04:23:26Z asedeno joined #sbcl
2014-11-01T04:30:52Z LiamH quit (Quit: Leaving.)
2014-11-01T04:53:55Z rszeno joined #sbcl
2014-11-01T04:55:56Z rszeno quit (Client Quit)
2014-11-01T05:02:01Z pranavrc joined #sbcl
2014-11-01T05:02:01Z pranavrc quit (Changing host)
2014-11-01T05:02:01Z pranavrc joined #sbcl
2014-11-01T05:09:52Z asedeno quit (Ping timeout: 250 seconds)
2014-11-01T05:10:10Z asedeno joined #sbcl
2014-11-01T06:06:50Z gingerale joined #sbcl
2014-11-01T06:32:48Z Intensity quit (Remote host closed the connection)
2014-11-01T06:43:45Z PuercoPop quit (Ping timeout: 272 seconds)
2014-11-01T06:46:44Z PuercoPop joined #sbcl
2014-11-01T07:03:12Z pranavrc quit (Remote host closed the connection)
2014-11-01T07:34:06Z pranavrc joined #sbcl
2014-11-01T07:34:06Z pranavrc quit (Changing host)
2014-11-01T07:34:06Z pranavrc joined #sbcl
2014-11-01T07:35:58Z pranavrc_ joined #sbcl
2014-11-01T07:35:59Z pranavrc quit (Read error: Connection reset by peer)
2014-11-01T07:40:22Z psy_ quit (Ping timeout: 240 seconds)
2014-11-01T07:40:32Z pranavrc_ quit (Ping timeout: 255 seconds)
2014-11-01T08:27:17Z psy_ joined #sbcl
2014-11-01T08:36:32Z pranavrc joined #sbcl
2014-11-01T08:36:32Z pranavrc quit (Changing host)
2014-11-01T08:36:32Z pranavrc joined #sbcl
2014-11-01T08:41:17Z pranavrc quit (Ping timeout: 255 seconds)
2014-11-01T08:43:05Z psy_ quit (Ping timeout: 255 seconds)
2014-11-01T09:01:04Z DGASAU quit (Ping timeout: 245 seconds)
2014-11-01T09:10:32Z attila_lendvai joined #sbcl
2014-11-01T09:10:32Z attila_lendvai quit (Changing host)
2014-11-01T09:10:32Z attila_lendvai joined #sbcl
2014-11-01T09:20:23Z DGASAU joined #sbcl
2014-11-01T09:37:23Z pranavrc joined #sbcl
2014-11-01T09:41:57Z pranavrc quit (Ping timeout: 245 seconds)
2014-11-01T09:56:29Z DGASAU quit (Ping timeout: 245 seconds)
2014-11-01T09:57:37Z DGASAU joined #sbcl
2014-11-01T09:58:59Z attila_lendvai quit (Ping timeout: 245 seconds)
2014-11-01T10:04:03Z psy_ joined #sbcl
2014-11-01T10:05:01Z pranavrc joined #sbcl
2014-11-01T10:46:08Z attila_lendvai joined #sbcl
2014-11-01T11:07:35Z loke_ joined #sbcl
2014-11-01T11:11:23Z pranavrc quit (Remote host closed the connection)
2014-11-01T11:11:32Z pranavrc joined #sbcl
2014-11-01T11:34:57Z fikusz quit (Remote host closed the connection)
2014-11-01T11:38:25Z fikusz joined #sbcl
2014-11-01T12:09:53Z oleo is now known as Guest78695
2014-11-01T12:10:45Z oleo__ joined #sbcl
2014-11-01T12:10:55Z wbooze quit (Ping timeout: 244 seconds)
2014-11-01T12:13:15Z Guest78695 quit (Ping timeout: 265 seconds)
2014-11-01T12:31:43Z LiamH joined #sbcl
2014-11-01T13:45:24Z cmack` joined #sbcl
2014-11-01T13:46:57Z cmack quit (Ping timeout: 265 seconds)
2014-11-01T14:09:41Z wbooze joined #sbcl
2014-11-01T15:06:11Z pranavrc quit
2014-11-01T16:37:14Z edgar-rft quit (Quit: the consequences are unspecified)
2014-11-01T17:03:08Z wbooze quit (Ping timeout: 250 seconds)
2014-11-01T17:32:36Z scymtym_ joined #sbcl
2014-11-01T18:01:15Z loke_ quit (Ping timeout: 265 seconds)
2014-11-01T18:13:43Z loke_ joined #sbcl
2014-11-01T18:20:00Z attila_lendvai quit (Quit: Leaving.)
2014-11-01T18:22:52Z krzysz00 joined #sbcl
2014-11-01T18:34:23Z attila_lendvai joined #sbcl
2014-11-01T18:34:33Z attila_lendvai quit (Changing host)
2014-11-01T18:34:33Z attila_lendvai joined #sbcl
2014-11-01T18:40:03Z attila_lendvai quit (Disconnected by services)
2014-11-01T18:40:04Z attila_lendvai1 joined #sbcl
2014-11-01T18:40:04Z attila_lendvai1 quit (Changing host)
2014-11-01T18:40:04Z attila_lendvai1 joined #sbcl
2014-11-01T18:42:15Z attila_lendvai joined #sbcl
2014-11-01T18:42:47Z attila_lendvai quit (Client Quit)
2014-11-01T18:42:55Z attila_lendvai joined #sbcl
2014-11-01T18:43:52Z attila_lendvai quit (Client Quit)
2014-11-01T18:44:00Z attila_lendvai joined #sbcl
2014-11-01T18:45:32Z attila_lendvai1 quit (Ping timeout: 256 seconds)
2014-11-01T18:48:37Z attila_lendvai quit (Ping timeout: 265 seconds)
2014-11-01T18:49:38Z attila_lendvai joined #sbcl
2014-11-01T18:49:38Z attila_lendvai quit (Changing host)
2014-11-01T18:49:38Z attila_lendvai joined #sbcl
2014-11-01T18:57:06Z attila_lendvai quit (Quit: Leaving.)
2014-11-01T19:06:04Z krzysz00 quit (Ping timeout: 260 seconds)
2014-11-01T19:07:51Z krzysz00 joined #sbcl
2014-11-01T19:12:54Z nyef joined #sbcl
2014-11-01T19:28:18Z krzysz00 quit (Ping timeout: 250 seconds)
2014-11-01T19:28:40Z krzysz00 joined #sbcl
2014-11-01T19:51:16Z attila_lendvai joined #sbcl
2014-11-01T19:57:15Z attila_lendvai1 joined #sbcl
2014-11-01T19:57:15Z attila_lendvai quit (Disconnected by services)
2014-11-01T19:57:15Z attila_lendvai1 quit (Changing host)
2014-11-01T19:57:15Z attila_lendvai1 joined #sbcl
2014-11-01T19:57:30Z oleo__ is now known as oleo
2014-11-01T20:00:42Z wbooze joined #sbcl
2014-11-01T20:24:53Z stassats joined #sbcl
2014-11-01T20:26:14Z stassats: and "CORRUPTION WARNING Memory fault at xxx" was being cut off on x86-64, how useful
2014-11-01T20:37:55Z Intensity joined #sbcl
2014-11-01T20:46:01Z stassats: i'm curious why we blow past the stack guards in that dx ticket
2014-11-01T20:46:54Z stassats: rbp doesn't seem to be where the stack is
2014-11-01T20:47:22Z LiamH quit (Quit: Leaving.)
2014-11-01T20:48:00Z stassats: or do we change the stack location on the initial thread? and /proc/maps still things that the stack is there?
2014-11-01T20:49:59Z stassats: ok, that does make more sense indeed
2014-11-01T20:50:55Z stassats: do we not have page guards for the initial thread or what?
2014-11-01T20:52:19Z nyef: This the most recent "I can dx-allocate past the end of the stack" ticket?
2014-11-01T20:53:02Z stassats: ok, i see what's going on
2014-11-01T20:54:43Z attila_lendvai1 quit (Ping timeout: 255 seconds)
2014-11-01T20:55:24Z stassats: we allocate a list backwards, so, the list end is way past the stack and its guard pages
2014-11-01T20:56:43Z stassats: well, not backwards, forwards, but the stack is growing down, so, it's against the flow of the stack
2014-11-01T21:00:19Z stassats: so, for all dx allocating things, it would be a good idea to grow the same direction as the stack
2014-11-01T21:00:59Z nyef: Even if you make that happen for LIST-OR-LIST*, you'll still have trouble with LISTIFY-REST-ARG.
2014-11-01T21:01:13Z stassats: that's the original troubly thing
2014-11-01T21:02:26Z nyef: I'd suggest dropping call-args-limit to the guard page size divided by the size of a cons in memory.
2014-11-01T21:03:11Z nyef: badda-bing badda-boom, you can no longer blow past the guard page with listifying the rest list on legal code.
2014-11-01T21:03:31Z stassats: but the same thing is with make-array, etc.
2014-11-01T21:03:53Z heddwch quit (Ping timeout: 265 seconds)
2014-11-01T21:04:02Z stassats: nyef: well, i don't care about the limit, and i don't want to insert length checks
2014-11-01T21:04:09Z nyef: Then you get into a matter of probing stack-allocated space on a pagewise basis to trigger the guard.
2014-11-01T21:04:49Z heddwch joined #sbcl
2014-11-01T21:05:02Z stassats: saying "ha, told ya!" isn't a good solution
2014-11-01T21:05:26Z stassats: i want to always stomp on the guard page
2014-11-01T21:06:21Z stassats: so, reversing the allocation direction will solve that, but i'm not sure whether heap allocation will like the reversed order
2014-11-01T21:06:39Z stassats: don't really want to have to versions of allocating code
2014-11-01T21:07:33Z attila_lendvai joined #sbcl
2014-11-01T21:07:49Z stassats: marked that bug as a duplicate
2014-11-01T21:08:19Z stassats: the original is only five years old
2014-11-01T21:08:37Z nyef: The high priority one or the low priority one?
2014-11-01T21:08:44Z stassats: the high one
2014-11-01T21:09:02Z nyef: So the other might even be six by now?
2014-11-01T21:09:42Z stassats: just about
2014-11-01T21:10:11Z attila_lendvai quit (Disconnected by services)
2014-11-01T21:10:11Z attila_lendvai1 joined #sbcl
2014-11-01T21:10:11Z attila_lendvai1 quit (Changing host)
2014-11-01T21:10:11Z attila_lendvai1 joined #sbcl
2014-11-01T21:10:16Z stassats: but my reasoning is: we don't have a call depth limit, then limiting the number of args is pointless
2014-11-01T21:10:53Z stassats: and making sure everything is backwards can solve the way-out-of-stack issues
2014-11-01T21:11:31Z stassats: need to identify what can dx allocate page large things
2014-11-01T21:12:09Z nyef: Structures of purely boxed slots and arrays come to mind. Also mixed structures on x86oids.
2014-11-01T21:12:34Z stassats: besides arrays and lists, right
2014-11-01T21:12:56Z stassats: page sized structures? sure you can have that, but that's unlikely
2014-11-01T21:13:36Z nyef: Possibly also instances?
2014-11-01T21:13:42Z stassats: and the only way of allocating a large list is by doing (list a b c ...), unlikelyish as well
2014-11-01T21:14:08Z stassats: nyef: don't think we can dx those, although they are just structures
2014-11-01T21:14:32Z stassats: and the structures are pretty small, the slots are in a vector, which is in a structure slot
2014-11-01T21:14:56Z stassats: so, the real issues are listify-rest-arg and allocate-vector-on-stack, so, maybe address those first
2014-11-01T21:15:06Z nyef: Mmm. I have no idea how most of the CLOS stuff works, or is even laid out in memory.
2014-11-01T21:15:40Z stassats: and not many people dx structures, you need to inline the constructor first
2014-11-01T21:16:08Z stassats: ok, great plan, now back to work, somebody will implement that in a couple of years...
2014-11-01T21:16:21Z nyef: Heh.
2014-11-01T21:16:54Z stassats: i better spend some time on getting rid of alloc_sap
2014-11-01T21:17:18Z stassats: just need to remove the instances on the win32 side
2014-11-01T21:17:42Z nyef: IIRC, only alloc_sap and alloc_code are used, and the other functions can be killed off directly.
2014-11-01T21:18:32Z stassats: alloc_number is used somewhere, but i think it isn't triggered or something
2014-11-01T21:20:00Z stassats: at least the ones in gc_heap_exhausted_error_or_lose
2014-11-01T21:20:15Z stassats: can available and requested be non-fixnums?
2014-11-01T21:20:39Z attila_lendvai1 quit (Ping timeout: 244 seconds)
2014-11-01T21:20:44Z stassats: maybe on 32 bit targets
2014-11-01T21:20:54Z nyef: available has to be a fixnum.
2014-11-01T21:21:04Z nyef: I'm not sure about requested.
2014-11-01T21:21:32Z nyef: Oh, wait. Maybe not.
2014-11-01T21:21:42Z nyef: What's the unit involved?
2014-11-01T21:22:00Z stassats: bytes
2014-11-01T21:23:19Z stassats: wait what
2014-11-01T21:23:24Z nyef: Mmm. So, assuming that the heap has to fit in the low 2G...
2014-11-01T21:23:34Z attila_lendvai joined #sbcl
2014-11-01T21:23:34Z attila_lendvai quit (Changing host)
2014-11-01T21:23:34Z attila_lendvai joined #sbcl
2014-11-01T21:23:44Z stassats: (type-of (make-array 2305843009213693951)) => (SIMPLE-VECTOR 2305843009213693951)
2014-11-01T21:23:49Z stassats: didn't i fix that already? sigh
2014-11-01T21:24:17Z stassats: (type-of (make-array 2305843009213693950)) => SB-KERNEL::RANDOM-CLASS
2014-11-01T21:24:25Z stassats: not again
2014-11-01T21:25:19Z stassats: maybe i wanted to fix it and didn't?
2014-11-01T21:31:27Z stassats: ok, it was 3bd011e1c200301c3bf15ff667214a0c1a61a7be
2014-11-01T21:32:47Z attila_lendvai quit (Read error: No route to host)
2014-11-01T21:36:26Z stassats: i probably didn't check things properly
2014-11-01T21:40:33Z stassats: this is more fun, (type-of (make-array (1- (expt 2 60)))) => total failure
2014-11-01T21:41:09Z prxq joined #sbcl
2014-11-01T21:45:58Z stassats: i guess the problem now is that now it doesn't go bonkers during shifting towards bytes, but when it's added to the current allocation pointer
2014-11-01T21:48:32Z attila_lendvai joined #sbcl
2014-11-01T21:50:50Z stassats: so ADD RAX, R11 CMP RAX, [R12+32]
2014-11-01T21:51:00Z stassats: maybe we should add an overflow check after ADD?
2014-11-01T21:59:41Z attila_lendvai quit (Read error: Connection reset by peer)
2014-11-01T22:00:54Z attila_lendvai joined #sbcl
2014-11-01T22:02:13Z attila_lendvai1 joined #sbcl
2014-11-01T22:02:13Z attila_lendvai quit (Disconnected by services)
2014-11-01T22:02:13Z attila_lendvai1 quit (Changing host)
2014-11-01T22:02:13Z attila_lendvai1 joined #sbcl
2014-11-01T22:11:47Z stassats: ok, the problem is in alignment
2014-11-01T22:11:55Z stassats: (logand (ldb (byte 64 0) (+ (ash (1- (expt 2 61)) 3) 31)) -16) => 16
2014-11-01T22:16:53Z stassats: ok, i can lower the limit up to alignment
2014-11-01T22:17:07Z stassats: and then make a comparison to be unsigned
2014-11-01T22:19:42Z stassats: or no, basically i have to say no to all the optimization in ALLOCATION regarding size addition
2014-11-01T22:20:35Z stassats: who cares about optimizations when things are wrong, though
2014-11-01T22:39:28Z krzysz00 quit (Ping timeout: 272 seconds)
2014-11-01T22:40:58Z krzysz00 joined #sbcl
2014-11-01T22:42:24Z stassats: ok, changing allocate-vector type to (integer 0 #. (- (1- (expt 2 (- sb!vm:n-word-bits sb!vm:word-shift))) 3))
2014-11-01T22:43:02Z stassats: and adding (inst jmp :c not-inline) after ADD "solves" the issue
2014-11-01T22:43:27Z stassats: GC invariant lost, file "gencgc.c", line 4431 with -16 passed to alloc
2014-11-01T22:44:37Z stassats: not sure why alloc and friends use signed for the number of bytes to allocate
2014-11-01T22:47:23Z stassats: i can stop questioning that decision and lower the limit one bit more
2014-11-01T22:52:52Z stassats: and that way i supposedly can't overflow alloc_ptr + byte_size
2014-11-01T22:52:54Z stassats: fine with me
2014-11-01T23:06:34Z stassats: so, There are still 12827623424 bytes available; the request was for 9223372036854775792 bytes.
2014-11-01T23:06:52Z stassats: 9223372036854775792 is not a fixnum
2014-11-01T23:13:48Z krzysz00 quit (Ping timeout: 244 seconds)
2014-11-01T23:16:59Z stassats: which means when heap exhausted is signalled, this thing may cause another allocation
2014-11-01T23:18:55Z stassats: allocate-vector limit is now lower, but i still can't lower array-total-size-limit because of bit vectors
2014-11-01T23:25:32Z edgar-rft joined #sbcl
2014-11-01T23:38:33Z nyef: I don't know why the units are bytes when the smallest allocation unit is two words.
2014-11-01T23:39:07Z stassats: because it's allocated in bytes eventually?
2014-11-01T23:46:24Z attila_lendvai1 quit (Quit: Leaving.)
2014-11-01T23:46:53Z psy_ quit (Ping timeout: 240 seconds)
2014-11-01T23:50:08Z LiamH joined #sbcl