Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-30

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:56 raiph optgen might be of interest; it calcs "all local optimizations up to a given cost limit" and gens corresponding compiler test suite; some other goodies too; http://pp.ipd.kit.edu/uploads/publikationen/buchwald15cc.pdf
02:34 hoelzro joined #moarvm
04:15 raiph joined #moarvm
04:50 prammer joined #moarvm
04:56 vendethiel joined #moarvm
05:32 TEttinger joined #moarvm
06:10 brrt joined #moarvm
06:12 brrt \o
06:12 brrt raiph: thanks, that's nice :-)
06:12 brrt jnthn: fixed it :-)
06:12 timotimo ohai brrt
06:13 brrt ohai timotimo
06:13 brrt how is it?
06:13 nwc10 o/
06:14 timotimo had a very rough night, sleep-wise
06:14 timotimo or sleep-attempt-wise
06:14 timotimo but i got to see the Prince of Persia: Sands of Time speed run
06:14 timotimo on SGDQ
06:15 brrt what.. is SGDQ
06:15 timotimo it was pretty amazing how the time rewind mechanic could be abused and broken to allow for travel in pretty much any direction for any distance
06:15 timotimo Summer Games Done Quick
06:15 timotimo a charity marathon of speedruns
06:15 brrt ah, cool
06:16 timotimo in The Sands of Time, you're supposed to be able to rewind time and end up right back where you were a bit of time ago, for example to undo a failed jump that'd kill you
06:16 brrt uhuh
06:16 timotimo but it turns out - and i don't know the exact details - that if you do tappy little steps before rewinding, the thing that implements it gets hugely confused and you'll end up flying straight forwards through any walls
06:16 timotimo or if you've jumped before you did the 19 tappy steps, you'll end up doing a gigantic jump - again, through basically any roof
06:17 brrt what
06:17 brrt that is weird
06:17 brrt how does that even compute
06:17 timotimo if you're a programmer you'll end up wondering how exactly it's implemented to cause this behavior
06:17 brrt right
06:17 brrt i can't imagine :-)
06:17 timotimo it's quite a feat to build such a thing and have it robust, as it also rewinds everything in the game world, even enemy AI
06:18 brrt hmm
06:18 timotimo maybe it has a fixed-length buffer where short steps take a significantly larger chunk than for example running in a straight line would
06:18 brrt that seems reasonably plausible
06:18 timotimo the mind ... it boggles! :)
06:20 brrt yes, it does
06:20 brrt not sure how far you can travel back?
06:22 timotimo the time you can travel back is fixed as in "fixed number of seconds", AIUI
06:22 brrt hmmm
06:22 brrt then i can imagine some kind of buffer overrun. but how would that be stable enough to exploit?
06:23 timotimo oh, don't mention the word "stable" in combination with this game
06:23 timotimo another fun thing that was going on last night was a Legend of Zelda: Swordless Run
06:24 timotimo where they played the original LoZ on the NES without picking up the sword at the beginning of the game
06:24 timotimo "let's figure out how dangerous it is exactly to go alone"
06:27 brrt oh, thats pretty cool
06:27 timotimo aye
06:30 FROGGS joined #moarvm
06:32 brrt i'm not 100% sure on how to represent the MVMJitTileRUle structure
06:32 brrt i kind of want to make 'm functions
06:33 brrt but some (most) run postorder, some run inorder, some run preorder and postorder (e.g. invokish)
06:34 brrt which is not all that well represented in a function pointer
06:34 timotimo put it into the lowest bits, i'm sure the cpu will just mask those :P :P
06:36 timotimo on every architecture we want to support
06:36 brrt hmmm
06:36 nwc10 on every architecture the JIT wants to support?
06:36 brrt that's hardly a bad idea
06:38 brrt no, it won't fly
06:38 timotimo oh, right, only the ones the jit will support
06:38 nwc10 which, I think is roughly x86_64 and ARM
06:38 nwc10 and if ARM varies much, assume ARMv7 and ARMv8
06:39 brrt but a combination of { function pointer, ordering-rules } would do quite well, i'd think
06:39 nwc10 effort spent trying to support more platforms than that would be much better spent instead on a better JIT on those two.
06:39 nwc10 (he says, opinionated style)
06:40 nwc10 if someone (er IBM) wants Power, they can pay for it :-)
06:40 nwc10 likewise MIIPS
06:40 brrt yeah, i tend to agree
06:40 nwc10 er, MIPS. and i don't know
06:40 brrt SPARC
06:40 brrt :-P
06:40 timotimo ALPHA
06:40 brrt luajit does support these things (at significant cost)
06:41 zakharyas joined #moarvm
06:41 FROGGS what about m68k?
06:41 * FROGGS hides
06:41 timotimo 8086
06:42 * FROGGS loved the m68k
06:43 brrt :-P
06:43 brrt why not ehm...  that-80s-architecture
06:43 brrt anyway
06:43 brrt we don't even support ARM, not now and not necessarily very soon
06:43 timotimo let's support that zuse computer thingie
06:44 timotimo or maybe the Connection Machine
06:44 FROGGS hmmm, an NQP stage0 on punchcards would be quite awesome to have at home
06:46 timotimo oh lord, that'd be humongous
06:47 FROGGS I mean, as a backup, you see :D
06:47 FROGGS and it is actually pretty easy to diff two sets
06:47 FROGGS easy, but not fast
06:48 timotimo FROGGS: do you have thoughts on allowing spawn, shell and spawnasync to supply more file descriptors than just 0, 1 and 2?
06:49 FROGGS hmmm
06:49 FROGGS like, from opening a file?
06:49 timotimo nah
06:49 timotimo well, yeah
06:49 timotimo that's one option
06:49 timotimo but also passing along pre-opened sockets, allowing communication back to the parent process via more different pipes, that sort of thing
06:50 FROGGS hmmm
06:50 timotimo systemd has this neato concept called "socket activation" where it listens on ports that you've declared your daemon is interested in, and it'll pass the accepted connection and listen socket right to your program as it gets spawned
06:51 FROGGS have thought about that for a split second when implementing the current ops, but said to myself that this should come afterwards
06:51 timotimo as long as it does come ... ;)
06:52 FROGGS well... it is more important (to me at least) to get the current ops working on windows
06:52 FROGGS it doesnt work yet when you spawn two or more subprocesses and chain their streams
06:52 bonsaikitten timotimo: xinetd, it's old tech
06:52 bonsaikitten timotimo: and we stopped using it for $reasons
06:53 timotimo i thought there's a difference between what xinetd does and what systemd does
06:54 bonsaikitten not really
06:54 timotimo but systemd also does lifecycle management of the whole daemon, which i believe xinetd wouldn't do
06:54 bonsaikitten yes
06:54 bonsaikitten and systemd moves /lib to /etc, /etc to /usr/lib, and other funnies
06:55 timotimo hehe
06:55 bonsaikitten xinetd was mostly abandoned because it's a DoS vector and startup failures are best seen at startup
06:55 bonsaikitten also no need to save 3MB RAM now just by avoiding to start something
06:56 timotimo mhm
07:02 brrt well, one of the clever bits of socket activation (imho) is that you can run a non-root process on a privileged port
07:08 timotimo mhm
07:08 Ven joined #moarvm
07:09 timotimo otherwise you'd have to do the privilege drop yourself
07:09 timotimo in this case, systemd does it for you
07:09 timotimo and if security critical stuff is done for you, that's better for you :)
07:12 brrt there's a tradeoff there, but sure
07:14 timotimo well, systemd is probably going to get more people looking at it and also updated more frequently anyway
07:14 bonsaikitten timotimo: as soon as the code stops being an undocumented horrible mess it might even be taken seriously ;)
07:16 * timotimo has no idea about that
07:16 * timotimo is also not very good at security-think
07:17 timotimo but not as clueless as some people seem to be
07:18 brrt well, i don't particularily want to get into discussions about what a real init system should look like or what it should and should not do
07:18 brrt i don't think i really care :-)
07:24 bonsaikitten I would like software
07:25 bonsaikitten y'know ... design documents, documented interfaces, documented code, etc.
07:25 bonsaikitten seems to be a very unusual concept
07:25 nwc10 a real init system provides decent coffee?
07:26 nwc10 jnthn: how is your init system today? :-)
07:26 brrt decent coffee seems to be a prerequisite, yes
07:26 brrt or tea, i can accept that too
07:27 brrt bonsaikitten: imho most software is experimentation, not engineering
07:27 bonsaikitten brrt: but even that can be well designed - e.g. documenting APIs
07:27 bonsaikitten where I mean documentation and not textbarf from doxygen
07:27 brrt 'gee, lets see if we can make this work' => 'how shall we scale it to 1000 machines'
07:27 bonsaikitten next person that says "doxygen writes documentation" gets slapped ;)
07:28 brrt well, yeah, but i think that's unreasonable considering the state of our work, or at least, in most cases
07:28 brrt i'd take a guess that 90% of software is never designed or engineered in any real sense
07:29 brrt (much like 90% of all construction work has no involvement of any engineering, since it's just routine)
07:30 brrt if you want 'good and proper documentation', that's a reasonable want, but it is the result of a thoughtful - engineering - process, not something we can will into life
07:30 brrt let me try to rephrase that
07:31 brrt the web platform (html/js/css) has truly copious amounts of documentation
07:31 brrt it is still hard, and things still don't work the way you should expect
07:35 brrt and (continuing post-interruption) i'd argue that this is mostly by lack of a real design effort
07:49 timotimo i was wondering if i ought to build an nqp op that gives you the bytecode segment of a routine and its annotations
07:49 timotimo and perhaps even all the spesh candidates with a bunch of metainfo about them
08:00 brrt well
08:00 brrt that'd be cool, *but*
08:00 brrt that's not really compatible with the lifecycle of the spesh graph
08:01 brrt you'd have to transform everything into a hashtable or array
08:01 timotimo oh i'm not refering to the spesh graph
08:01 timotimo just the generated bytecode
08:01 timotimo but spesh graph would be much cooler
08:03 brrt hmm
08:03 brrt generated bytecode, i could see how you could make a simple list of bytecode-names, maybe a lol of bytecodename, operands
08:04 timotimo we already have a perl6 module generated by update_oplist.p6
08:05 brrt oh yes, that's true
08:05 timotimo in that same module we could also put a disassemble sub
08:07 brrt i suppose so, yes
08:21 * jnthn yawns
08:22 jnthn I think spesh should remain entirely internal to MoarVM (except the various environmental debugging/configuration things), not be exposed. Otherwise we can't so easily change it.
08:23 timotimo mhm
08:23 * nwc10 would agree with that.
08:23 timotimo i was thinking if we have an op for that, a user of a debugger could let it print out the vm-level instructions
08:24 timotimo hm, turns out my "livecoding tool" is also broken without me trying to make gtk source view work with it
08:25 timotimo it's doing the infamous "unwound entire stack and missed handler" thing, even though i littered all callbacks with try/catch
08:25 timotimo with "use trace" i even see it execute "CATCH { say $_ }"
08:25 timotimo but i see no output
08:25 brrt jnthn: libcoffee has loaded?
08:26 jnthn brrt: Still loading... :)
08:27 * jnthn tried to catch up a bit on sleep since he didn't sleep too well a couple of the nights while away teaching
08:27 brrt sleep is for the weak
08:27 brrt or something something
08:27 brrt :-P
08:29 timotimo $da.add_draw_handler( -> $widget, $ctx { } ); makes my program crash
08:29 brrt where does it crash?
08:30 timotimo ah
08:30 timotimo my $cairo = nqp::box_i($cairop.Int, $cairo_t);
08:30 timotimo "this type cannot box a native integer"
08:30 timotimo ah
08:30 timotimo cairo is not installed, and it gives a very LTA error message
08:54 dalek MoarVM/even-moar-jit: c6d15d4 | brrt++ | / (9 files):
08:54 dalek MoarVM/even-moar-jit: Small fixes, rename expression file
08:54 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c6d15d4582
09:14 brrt new wingolog: http://wingolog.org/archives/2015/07/28/loop-optimizations-in-guile
09:16 sergot joined #moarvm
09:18 zakharyas joined #moarvm
09:43 dalek MoarVM/even-moar-jit: 8a29e93 | brrt++ | src/ (4 files):
09:43 dalek MoarVM/even-moar-jit: Cleanup jit graph and expr tree after use
09:43 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/8a29e938b8
09:56 rurban_ joined #moarvm
09:56 Ven joined #moarvm
10:08 Ven joined #moarvm
10:43 nwc10 jnthn: t/spec/S17-procasync/no-runaway-file-limit.t seems to be capable of getting itself deadlocked
10:43 nwc10 or some other form of hanging
10:44 nwc10 18 thrads, doing quite a few different things.
10:48 jnthn Interesting. Never seen it do that on Windows, fwiw.
10:57 nwc10 jnthn: here's a "summary" http://paste.scsys.co.uk/496244
10:57 nwc10 I only did the first thread that waited at any given function
10:59 jnthn Those stack traces are confusing as hell...
10:59 jnthn Oh, maybe the JITted frames confuse it
10:59 nwc10 yes, the JIT seems to confuse gdb
10:59 nwc10 at least, that gdb
10:59 jnthn It looks like it's hanging when trying to GC
11:00 jnthn It's not immediately obvious why.
11:20 brrt joined #moarvm
11:24 brrt hey, dead JIT issues?
11:25 nwc10 not sure.
11:25 nwc10 but, hey, that apepars to be be the answer
11:25 nwc10 disable SPESH
11:25 nwc10 and repeat running the test
11:25 nwc10 until it hangs
11:25 nwc10 or I get bored of trying
11:31 brrt well, i'm more worried about dead JITs than dead spesh
11:31 brrt dead spesh typically means memory got corrupted somewhere
11:31 brrt eh, dead JIT
11:36 brrt i'm kind of confused on what to do now
11:37 nwc10 brrt: jnthn and I don't think that it's a JIT bug
11:37 brrt hmm
11:37 nwc10 we're supsicious that it's merely JIT confusing the backtrace
11:37 nwc10 I have this deja vu feeling about that statement
11:37 brrt that's quite likely, yes
11:37 nwc10 last year?
11:37 brrt if i knew how to make gdb happy about the JITted frame, i would
11:38 brrt by the way, isn't it funny how the JITted code is truly internalized into the program?
11:46 brrt hmm
11:48 brrt i can't really concentrate now
12:06 nwc10 odd
12:06 nwc10 t/spec/S15-nfg/many-threads.t just failed for me
12:06 nwc10 Parse errors: Bad plan.  You planned 4 tests but ran 0.
12:06 nwc10 I don't remmeber that happening before
12:06 nwc10 I don't have more output
12:08 nwc10 oooh, ASAN technicolor barfage: http://paste.scsys.co.uk/496255
12:09 nwc10 roughly repeatable under MVM_SPESH_DISABLE=1
12:13 brrt joined #moarvm
12:19 brrt hmm,  that looks pretty bad
12:19 brrt i wonder why that happens
12:21 Ven joined #moarvm
12:38 jnthn lexotic, eh...
12:41 jnthn Hm, the lexotic cache is held per thread.
12:45 Ven joined #moarvm
12:53 jnthn Despite all the allocation going on, causing 593 GC runs, the time doing GC only amounts to 2.5% of runtime.
12:54 jnthn ops, ww
13:04 jnthn Aha, think I found it
13:17 raiph joined #moarvm
13:18 jnthn nwc10: I didn't manage to reproduce any crashes here, but I think I understand what's up
13:18 jnthn nwc10: Will push a patch for you to try out
13:18 nwc10 OK
13:19 dalek MoarVM/even-moar-jit: e016534 | brrt++ | src/jit/ (4 files):
13:19 dalek MoarVM/even-moar-jit: Add a few expr templates, fix bug with coderef idx
13:19 dalek MoarVM/even-moar-jit:
13:19 dalek MoarVM/even-moar-jit: A coderef idx is really nothing like an ins_offset
13:19 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e0165347d3
13:19 nwc10 I think I have about an hour
13:19 nwc10 and then the grand moving circus kicks off
13:20 nwc10 and I'm probably rather busy until Sunday
13:21 jnthn Just checking patch is at least sanity-test-and-build-passing
13:24 dalek MoarVM: 04f336d | jnthn++ | src/core/bytecode.c:
13:24 dalek MoarVM: Fix a missing lock release.
13:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/04f336d105
13:24 dalek MoarVM: f89d760 | jnthn++ | src/core/frame.c:
13:24 dalek MoarVM: Avoid concurrent frame prepare/validate.
13:24 dalek MoarVM:
13:24 dalek MoarVM: While the validation itself is idempotent, the assigning of a lexotic
13:24 dalek MoarVM: pool index decidedly is not. Should fix a crash reported by nwc10++.
13:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f89d76064c
13:25 nwc10 jnthn: OK, running t/spec/S15-nfg/many-threads.t in a loop
13:26 nwc10 3 passes so far
13:26 donaldh joined #moarvm
13:26 FROGGS how reproducy was it before?
13:26 nwc10 failed on the first or second run
13:26 nwc10 8 passes now.
13:27 nwc10 looks likely that this fixed it
13:27 FROGGS nice
13:27 jnthn :)
13:27 jnthn The fix fitted the symptoms very closely
13:27 FROGGS bbl
13:32 JimmyZ jnthn: re 04f336d105, there is some 'throw' in MVM_sc_get_sc/get_heap_string too , did there  miss a lock release too?
13:35 jnthn JimmyZ: Those two probably want to become panics, since they're not likely easily recoverable from
13:35 JimmyZ OK :)
13:42 jnthn https://rt.perl.org/Ticket/Display.html?id=125480 is an odd one
13:54 brrt probably from jumping into the wrong place
13:55 TimToady joined #moarvm
14:00 jnthn hah, think I foudn it
14:00 jnthn *found
14:13 dalek MoarVM: bbe6231 | jnthn++ | src/core/interp.c:
14:13 dalek MoarVM: Fix extop "did interpreter move" check.
14:13 dalek MoarVM:
14:13 dalek MoarVM: Should consider the program counter, not the frame, since exceptions
14:13 dalek MoarVM: may move us within a frame.
14:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bbe6231fdd
14:15 Ven joined #moarvm
15:03 hoelzro_ii joined #moarvm
15:21 donaldh joined #moarvm
16:22 FROGGS joined #moarvm
17:11 njmurphy joined #moarvm
18:32 flussenc1 joined #moarvm
18:32 TEttinger joined #moarvm
18:34 sergot_ joined #moarvm
18:37 vendethiel joined #moarvm
18:50 timotimo getting a segv in MVM_6model_stable_gc_free ... pretty much everything inside the STable is null
18:50 timotimo $3 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 0, flags = 0,
18:50 timotimo size = 0}, REPR = 0x0, REPR_data = 0x0, size = 0, type_check_cache_length = 0, mode_flags = 0,
18:50 timotimo type_check_cache = 0x0, method_cache = 0x0, type_cache_id = 0, container_spec = 0x0, container_data = 0x0,
18:50 timotimo boolification_spec = 0x0, hll_owner = 0x0, hll_role = 0, invoke = 0x0, invocation_spec = 0x0, WHAT = 0x0,
18:50 timotimo WHO = 0x0, HOW = 0x0, paramet = {ric = {parameterizer = 0x0, lookup = 0x0}, erized = {parametric_type = 0x0,
18:51 timotimo parameters = 0x0}}, HOW_sc = 0x0, HOW_idx = 0, method_cache_offset = 0, method_cache_sc = 0x0}
18:51 timotimo and it tries to see if the ->REPR->gc_free_repr_data, which blows up when trying to deref the REPR
18:51 jnthn There's an RT with similar symptoms
18:52 jnthn How many threads running?
18:53 timotimo this is a gtk based app, so probably two, gimme a sec
18:53 jnthn And what's below that function in the stack?
18:53 jnthn Hm, but MoarVM level ones, or?
18:53 timotimo .o( how do i ask gds this ... )
18:53 jnthn No idea ;)
18:54 timotimo there are 6 threads, one of them is "gdbus", the rest are "moar"
18:54 timotimo this is enter_from_allocator -> gc_collect_free_stables
18:54 jnthn Is the memory address of the STable in some fromspace/tospace?
18:56 timotimo fromspace is 0x7ffff1392010, tospace is 0x7ffff0f91010, the stable is at 0x7ffff76e4590
18:56 timotimo so it seems to be in gen2 at that point
18:58 jnthn How reliably can you reproduce it?
18:59 jnthn I'm wondering if we're ending up consuming the STable "to free" list at the same time we're appending to it. The appends are threadsafe but the consumption may not be
19:00 timotimo let me try
19:01 timotimo rather reliably, i only once not gotten it in about 7 tries
19:02 timotimo shall i asan, valgrind or helgrind it?
19:02 timotimo that may be problematic with gtk in the codepaths
19:02 Ven joined #moarvm
19:02 jnthn You can try
19:03 timotimo if it's asan, and gtk isn't built with asan, it may be less terrible
19:03 timotimo as gtk wouldn't use the asanified allocator, right?
19:04 jnthn aye
19:04 timotimo let me grab the newest fixes and commits from today :)
19:07 timotimo makes it harder to reproduce
19:07 timotimo apparently --asan makes it not happen?
19:10 jnthn hmm
19:10 timotimo ==2635==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000168 (pc 0x7f54facf5c35 bp 0x7f54f0608720 sp 0x7f54f0608710 T4)
19:10 timotimo #0 0x7f54facf5c34 in MVM_6model_stable_gc_free src/6model/6model.c:398
19:10 jnthn Looking more closely
19:10 timotimo #1 0x7f54fac7196a in MVM_gc_collect_free_stables src/gc/collect.c:595
19:10 timotimo not that helpful :\
19:10 jnthn The only place we call MVM_gc_collect_enqueue_stable_for_deletion
19:10 jnthn Is on nursery objects or on global destruction
19:10 timotimo that'd hardly be problematic
19:12 jnthn But the pointer you had was not in the nursery, right?
19:12 timotimo it wasn't when i had it open in gdb
19:13 jnthn Maybe do a non-ASAN build
19:13 jnthn And
19:13 jnthn Put a printf before line 688
19:14 jnthn Like "oops" :)
19:14 zakharyas joined #moarvm
19:14 timotimo line 688, does that belong collect_enqueue_stable_for_deletion?
19:14 timotimo belong to*?
19:15 jnthn yeah
19:15 jnthn I want to see if your program is reaching that call
19:16 jnthn I may see what's going on
19:16 timotimo mhm
19:16 jnthn And if you are hitting that sometime before your crash, it'd be suggestive
19:17 timotimo "use trace" seems to make it worse
19:18 timotimo as in:
19:18 timotimo when i remove use trace - so that i can see "oops" more easily, it gets harder to reproduce
19:18 timotimo probably just means more pressure on the gc
19:18 jnthn *nod*
19:18 timotimo that line doesn't get hit in the event of a crash
19:18 jnthn hm :(
19:19 jnthn I still suspect a bug
19:20 jnthn It uses MVM_load(&tc->gc_status) == MVMGCStatus_NONE to infer that we're in global destruction mode
19:21 jnthn But in gc_finish we do
19:21 jnthn MVM_cas(&other->gc_status, MVMGCStatus_INTERRUPT, MVMGCStatus_NONE);
19:21 jnthn uh, finish_gc even
19:22 jnthn And MVM_gc_collect_free_gen2_unmarked is called that
19:22 jnthn So I'm fairly confident it's wrong.
19:22 timotimo mhm
19:23 jnthn It would have explained what you saw nicely, except it doesn't match too well with the lack of oops
19:23 timotimo good thing you stumbled over that
19:23 timotimo it could have caught someone soon-ish, or perhaps already has in the past
19:24 dalek MoarVM: d4ac6af | jnthn++ | src/gc/ (3 files):
19:24 dalek MoarVM: Don't infer global destruction from GC status.
19:24 dalek MoarVM:
19:24 dalek MoarVM: It gets cleared already by the time we do the check. Instead, just use
19:24 dalek MoarVM: a flag to explicitly say if that's what we're doing.
19:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d4ac6afa75
19:24 jnthn You could always try the patch...
19:25 jnthn Oh, also
19:25 jnthn Note that if you have many threads you have many nurseries
19:26 jnthn So if you were just looking at the tc of the one then you may still have had a nursery pointer
19:26 jnthn Just from another thread
19:26 timotimo oh!
19:26 timotimo d'uh
19:26 timotimo that's a very good point
19:28 timotimo still get that exception
19:28 timotimo er, segfault i mean
19:28 jnthn OK. So, worth patching, but not The Bug
19:30 timotimo mhm
19:32 timotimo hm, it does seem the stable is actually not in any of the nurseries
19:33 timotimo i went through all threads this time
19:33 jnthn Hmm
19:36 * jnthn is quite tired, so probably should leave hunting this further until tomorrow :)
19:37 timotimo stables_to_free = 0x7ffff7671490,  ← that's the address of the thing getting free'd at that very point
19:37 timotimo maybe we're not properly clearing that field?
19:37 timotimo (also, is that supposed to be the head of a linked list? or just an array with a "length" entry nearby?
19:37 timotimo - this is MVMInstance btw)
19:38 timotimo oh, we just set an st's ST as the next entry of the linked list
19:39 timotimo the code for that looks all right
19:46 timotimo another annoying thing: the monospace property of TextView doesn't change the font :|
19:48 timotimo can't really tell if my code is doing it right, that is
19:56 Ven joined #moarvm
20:38 raiph joined #moarvm
21:22 raiph joined #moarvm
23:21 Peter_R joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary