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; pp.ipd.kit.edu/uploads/publikatione...ld15cc.pdf 00:56
02:34 hoelzro joined 04:15 raiph joined 04:50 prammer joined 04:56 vendethiel joined 05:32 TEttinger joined 06:10 brrt joined
brrt \o 06:12
raiph: thanks, that's nice :-)
jnthn: fixed it :-)
timotimo ohai brrt
brrt ohai timotimo 06:13
how is it?
nwc10 o/
timotimo had a very rough night, sleep-wise 06:14
or sleep-attempt-wise
but i got to see the Prince of Persia: Sands of Time speed run
on SGDQ
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
Summer Games Done Quick
a charity marathon of speedruns
brrt ah, cool
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
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
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
brrt what 06:17
that is weird
how does that even compute
timotimo if you're a programmer you'll end up wondering how exactly it's implemented to cause this behavior
brrt right
i can't imagine :-)
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
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
brrt that seems reasonably plausible
timotimo the mind ... it boggles! :)
brrt yes, it does 06:20
not sure how far you can travel back?
timotimo the time you can travel back is fixed as in "fixed number of seconds", AIUI 06:22
brrt hmmm
then i can imagine some kind of buffer overrun. but how would that be stable enough to exploit?
timotimo oh, don't mention the word "stable" in combination with this game 06:23
another fun thing that was going on last night was a Legend of Zelda: Swordless Run
where they played the original LoZ on the NES without picking up the sword at the beginning of the game 06:24
"let's figure out how dangerous it is exactly to go alone"
brrt oh, thats pretty cool 06:27
timotimo aye
06:30 FROGGS joined
brrt i'm not 100% sure on how to represent the MVMJitTileRUle structure 06:32
i kind of want to make 'm functions
but some (most) run postorder, some run inorder, some run preorder and postorder (e.g. invokish) 06:33
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
on every architecture we want to support 06:36
brrt hmmm
nwc10 on every architecture the JIT wants to support?
brrt that's hardly a bad idea
no, it won't fly 06:38
timotimo oh, right, only the ones the jit will support
nwc10 which, I think is roughly x86_64 and ARM
and if ARM varies much, assume ARMv7 and ARMv8
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.
(he says, opinionated style)
if someone (er IBM) wants Power, they can pay for it :-) 06:40
likewise MIIPS
brrt yeah, i tend to agree
nwc10 er, MIPS. and i don't know
brrt SPARC
:-P
timotimo ALPHA
brrt luajit does support these things (at significant cost)
06:41 zakharyas joined
FROGGS what about m68k? 06:41
FROGGS hides
timotimo 8086
FROGGS loved the m68k 06:42
brrt :-P 06:43
why not ehm... that-80s-architecture
anyway
we don't even support ARM, not now and not necessarily very soon
timotimo let's support that zuse computer thingie
or maybe the Connection Machine 06:44
FROGGS hmmm, an NQP stage0 on punchcards would be quite awesome to have at home
timotimo oh lord, that'd be humongous 06:46
FROGGS I mean, as a backup, you see :D 06:47
and it is actually pretty easy to diff two sets
easy, but not fast
timotimo FROGGS: do you have thoughts on allowing spawn, shell and spawnasync to supply more file descriptors than just 0, 1 and 2? 06:48
FROGGS hmmm 06:49
like, from opening a file?
timotimo nah
well, yeah
that's one option
but also passing along pre-opened sockets, allowing communication back to the parent process via more different pipes, that sort of thing
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
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 ... ;)
FROGGS well... it is more important (to me at least) to get the current ops working on windows 06:52
it doesnt work yet when you spawn two or more subprocesses and chain their streams
bonsaikitten timotimo: xinetd, it's old tech
timotimo: and we stopped using it for $reasons
timotimo i thought there's a difference between what xinetd does and what systemd does 06:53
bonsaikitten not really 06:54
timotimo but systemd also does lifecycle management of the whole daemon, which i believe xinetd wouldn't do
bonsaikitten yes
and systemd moves /lib to /etc, /etc to /usr/lib, and other funnies
timotimo hehe 06:55
bonsaikitten xinetd was mostly abandoned because it's a DoS vector and startup failures are best seen at startup
also no need to save 3MB RAM now just by avoiding to start something
timotimo mhm 06:56
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:02
timotimo mhm 07:08
07:08 Ven joined
timotimo otherwise you'd have to do the privilege drop yourself 07:09
in this case, systemd does it for you
and if security critical stuff is done for you, that's better for you :)
brrt there's a tradeoff there, but sure 07:12
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 ;)
timotimo has no idea about that 07:16
timotimo is also not very good at security-think
but not as clueless as some people seem to be 07:17
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
i don't think i really care :-)
bonsaikitten I would like software 07:24
y'know ... design documents, documented interfaces, documented code, etc. 07:25
seems to be a very unusual concept
nwc10 a real init system provides decent coffee?
jnthn: how is your init system today? :-) 07:26
brrt decent coffee seems to be a prerequisite, yes
or tea, i can accept that too
bonsaikitten: imho most software is experimentation, not engineering 07:27
bonsaikitten brrt: but even that can be well designed - e.g. documenting APIs
where I mean documentation and not textbarf from doxygen
brrt 'gee, lets see if we can make this work' => 'how shall we scale it to 1000 machines'
bonsaikitten next person that says "doxygen writes documentation" gets slapped ;)
brrt well, yeah, but i think that's unreasonable considering the state of our work, or at least, in most cases 07:28
i'd take a guess that 90% of software is never designed or engineered in any real sense
(much like 90% of all construction work has no involvement of any engineering, since it's just routine) 07:29
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
let me try to rephrase that
the web platform (html/js/css) has truly copious amounts of documentation 07:31
it is still hard, and things still don't work the way you should expect
and (continuing post-interruption) i'd argue that this is mostly by lack of a real design effort 07:35
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
and perhaps even all the spesh candidates with a bunch of metainfo about them
brrt well 08:00
that'd be cool, *but*
that's not really compatible with the lifecycle of the spesh graph
you'd have to transform everything into a hashtable or array 08:01
timotimo oh i'm not refering to the spesh graph
just the generated bytecode
but spesh graph would be much cooler
brrt hmm 08:03
generated bytecode, i could see how you could make a simple list of bytecode-names, maybe a lol of bytecodename, operands
timotimo we already have a perl6 module generated by update_oplist.p6 08:04
brrt oh yes, that's true 08:05
timotimo in that same module we could also put a disassemble sub
brrt i suppose so, yes 08:07
jnthn yawns 08:21
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:22
timotimo mhm 08:23
nwc10 would agree with that.
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
hm, turns out my "livecoding tool" is also broken without me trying to make gtk source view work with it 08:24
it's doing the infamous "unwound entire stack and missed handler" thing, even though i littered all callbacks with try/catch 08:25
with "use trace" i even see it execute "CATCH { say $_ }"
but i see no output
brrt jnthn: libcoffee has loaded?
jnthn brrt: Still loading... :) 08:26
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
or something something
:-P
timotimo $da.add_draw_handler( -> $widget, $ctx { } ); makes my program crash 08:29
brrt where does it crash?
timotimo ah 08:30
my $cairo = nqp::box_i($cairop.Int, $cairo_t);
"this type cannot box a native integer"
ah
cairo is not installed, and it gives a very LTA error message
dalek arVM/even-moar-jit: c6d15d4 | brrt++ | / (9 files):
Small fixes, rename expression file
 08:54
brrt new wingolog: wingolog.org/archives/2015/07/28/lo...s-in-guile 09:14
09:16 sergot joined 09:18 zakharyas joined
dalek arVM/even-moar-jit: 8a29e93 | brrt++ | src/ (4 files):
Cleanup jit graph and expr tree after use
 09:43
09:56 rurban_ joined, Ven joined 10:08 Ven joined
nwc10 jnthn: t/spec/S17-procasync/no-runaway-file-limit.t seems to be capable of getting itself deadlocked 10:43
or some other form of hanging
18 thrads, doing quite a few different things. 10:44
jnthn Interesting. Never seen it do that on Windows, fwiw. 10:48
nwc10 jnthn: here's a "summary" paste.scsys.co.uk/496244 10:57
I only did the first thread that waited at any given function
jnthn Those stack traces are confusing as hell... 10:59
Oh, maybe the JITted frames confuse it
nwc10 yes, the JIT seems to confuse gdb
at least, that gdb
jnthn It looks like it's hanging when trying to GC
It's not immediately obvious why. 11:00
11:20 brrt joined
brrt hey, dead JIT issues? 11:24
nwc10 not sure. 11:25
but, hey, that apepars to be be the answer
disable SPESH
and repeat running the test
until it hangs
or I get bored of trying
brrt well, i'm more worried about dead JITs than dead spesh 11:31
dead spesh typically means memory got corrupted somewhere
eh, dead JIT
i'm kind of confused on what to do now 11:36
nwc10 brrt: jnthn and I don't think that it's a JIT bug 11:37
brrt hmm
nwc10 we're supsicious that it's merely JIT confusing the backtrace
I have this deja vu feeling about that statement
brrt that's quite likely, yes
nwc10 last year?
brrt if i knew how to make gdb happy about the JITted frame, i would
by the way, isn't it funny how the JITted code is truly internalized into the program? 11:38
hmm 11:46
i can't really concentrate now 11:48
nwc10 odd 12:06
t/spec/S15-nfg/many-threads.t just failed for me
Parse errors: Bad plan. You planned 4 tests but ran 0.
I don't remmeber that happening before
I don't have more output
oooh, ASAN technicolor barfage: paste.scsys.co.uk/496255 12:08
roughly repeatable under MVM_SPESH_DISABLE=1 12:09
12:13 brrt joined
brrt hmm, that looks pretty bad 12:19
i wonder why that happens
12:21 Ven joined
jnthn lexotic, eh... 12:38
Hm, the lexotic cache is held per thread. 12:41
12:45 Ven joined
jnthn Despite all the allocation going on, causing 593 GC runs, the time doing GC only amounts to 2.5% of runtime. 12:53
ops, ww 12:54
Aha, think I found it 13:04
13:17 raiph joined
jnthn nwc10: I didn't manage to reproduce any crashes here, but I think I understand what's up 13:18
nwc10: Will push a patch for you to try out
nwc10 OK
dalek arVM/even-moar-jit: e016534 | brrt++ | src/jit/ (4 files):
Add a few expr templates, fix bug with coderef idx

A coderef idx is really nothing like an ins_offset		 13:19
nwc10 I think I have about an hour
and then the grand moving circus kicks off
and I'm probably rather busy until Sunday 13:20
jnthn Just checking patch is at least sanity-test-and-build-passing 13:21
dalek arVM: 04f336d | jnthn++ | src/core/bytecode.c:
Fix a missing lock release.
 13:24
arVM: f89d760 | jnthn++ | src/core/frame.c:
Avoid concurrent frame prepare/validate.

While the validation itself is idempotent, the assigning of a lexotic pool index decidedly is not. Should fix a crash reported by nwc10++.
nwc10 jnthn: OK, running t/spec/S15-nfg/many-threads.t in a loop 13:25
3 passes so far 13:26
13:26 donaldh joined
FROGGS how reproducy was it before? 13:26
nwc10 failed on the first or second run
8 passes now.
looks likely that this fixed it 13:27
FROGGS nice
jnthn :)
The fix fitted the symptoms very closely
FROGGS bbl
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:32
jnthn JimmyZ: Those two probably want to become panics, since they're not likely easily recoverable from 13:35
JimmyZ OK :)
jnthn rt.perl.org/Ticket/Display.html?id=125480 is an odd one 13:42
brrt probably from jumping into the wrong place 13:54
13:55 TimToady joined
jnthn hah, think I foudn it 14:00
*found
dalek arVM: bbe6231 | jnthn++ | src/core/interp.c:
Fix extop "did interpreter move" check.

Should consider the program counter, not the frame, since exceptions may move us within a frame.		 14:13
14:15 Ven joined 15:03 hoelzro_ii joined 15:21 donaldh joined 16:22 FROGGS joined 17:11 njmurphy joined 18:32 flussenc1 joined, TEttinger joined 18:34 sergot_ joined 18:37 vendethiel joined
timotimo getting a segv in MVM_6model_stable_gc_free ... pretty much everything inside the STable is null 18:50
$3 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 0, flags = 0,
size = 0}, REPR = 0x0, REPR_data = 0x0, size = 0, type_check_cache_length = 0, mode_flags = 0,
type_check_cache = 0x0, method_cache = 0x0, type_cache_id = 0, container_spec = 0x0, container_data = 0x0,
boolification_spec = 0x0, hll_owner = 0x0, hll_role = 0, invoke = 0x0, invocation_spec = 0x0, WHAT = 0x0,
WHO = 0x0, HOW = 0x0, paramet = {ric = {parameterizer = 0x0, lookup = 0x0}, erized = {parametric_type = 0x0,
parameters = 0x0}}, HOW_sc = 0x0, HOW_idx = 0, method_cache_offset = 0, method_cache_sc = 0x0} 18:51
and it tries to see if the ->REPR->gc_free_repr_data, which blows up when trying to deref the REPR
jnthn There's an RT with similar symptoms
How many threads running? 18:52
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?
Hm, but MoarVM level ones, or?
timotimo .o( how do i ask gds this ... )
jnthn No idea ;)
timotimo there are 6 threads, one of them is "gdbus", the rest are "moar" 18:54
this is enter_from_allocator -> gc_collect_free_stables
jnthn Is the memory address of the STable in some fromspace/tospace?
timotimo fromspace is 0x7ffff1392010, tospace is 0x7ffff0f91010, the stable is at 0x7ffff76e4590 18:56
so it seems to be in gen2 at that point
jnthn How reliably can you reproduce it? 18:58
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 18:59
timotimo let me try 19:00
rather reliably, i only once not gotten it in about 7 tries 19:01
shall i asan, valgrind or helgrind it? 19:02
that may be problematic with gtk in the codepaths
19:02 Ven joined
jnthn You can try 19:02
timotimo if it's asan, and gtk isn't built with asan, it may be less terrible 19:03
as gtk wouldn't use the asanified allocator, right?
jnthn aye 19:04
timotimo let me grab the newest fixes and commits from today :)
makes it harder to reproduce 19:07
apparently --asan makes it not happen?
jnthn hmm 19:10
timotimo ==2635==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000168 (pc 0x7f54facf5c35 bp 0x7f54f0608720 sp 0x7f54f0608710 T4)
#0 0x7f54facf5c34 in MVM_6model_stable_gc_free src/6model/6model.c:398
jnthn Looking more closely
timotimo #1 0x7f54fac7196a in MVM_gc_collect_free_stables src/gc/collect.c:595
not that helpful :\
jnthn The only place we call MVM_gc_collect_enqueue_stable_for_deletion
Is on nursery objects or on global destruction
timotimo that'd hardly be problematic
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
jnthn Maybe do a non-ASAN build 19:13
And
Put a printf before line 688
Like "oops" :) 19:14
19:14 zakharyas joined
timotimo line 688, does that belong collect_enqueue_stable_for_deletion? 19:14
belong to*?
jnthn yeah 19:15
I want to see if your program is reaching that call
I may see what's going on 19:16
timotimo mhm
jnthn And if you are hitting that sometime before your crash, it'd be suggestive
timotimo "use trace" seems to make it worse 19:17
as in: 19:18
when i remove use trace - so that i can see "oops" more easily, it gets harder to reproduce
probably just means more pressure on the gc
jnthn *nod*
timotimo that line doesn't get hit in the event of a crash
jnthn hm :(
I still suspect a bug 19:19
It uses MVM_load(&tc->gc_status) == MVMGCStatus_NONE to infer that we're in global destruction mode 19:20
But in gc_finish we do 19:21
MVM_cas(&other->gc_status, MVMGCStatus_INTERRUPT, MVMGCStatus_NONE);
uh, finish_gc even
And MVM_gc_collect_free_gen2_unmarked is called that 19:22
So I'm fairly confident it's wrong.
timotimo mhm
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
it could have caught someone soon-ish, or perhaps already has in the past
dalek arVM: d4ac6af | jnthn++ | src/gc/ (3 files):
Don't infer global destruction from GC status.

It gets cleared already by the time we do the check. Instead, just use a flag to explicitly say if that's what we're doing.		 19:24
jnthn You could always try the patch...
Oh, also 19:25
Note that if you have many threads you have many nurseries
So if you were just looking at the tc of the one then you may still have had a nursery pointer 19:26
Just from another thread
timotimo oh!
d'uh
that's a very good point
still get that exception 19:28
er, segfault i mean
jnthn OK. So, worth patching, but not The Bug
timotimo mhm 19:30
hm, it does seem the stable is actually not in any of the nurseries 19:32
i went through all threads this time 19:33
jnthn Hmm
jnthn is quite tired, so probably should leave hunting this further until tomorrow :) 19:36
timotimo stables_to_free = 0x7ffff7671490, ← that's the address of the thing getting free'd at that very point 19:37
maybe we're not properly clearing that field?
(also, is that supposed to be the head of a linked list? or just an array with a "length" entry nearby?
- this is MVMInstance btw)
oh, we just set an st's ST as the next entry of the linked list 19:38
the code for that looks all right 19:39
another annoying thing: the monospace property of TextView doesn't change the font :| 19:46
can't really tell if my code is doing it right, that is 19:48
19:56 Ven joined 20:38 raiph joined 21:22 raiph joined 23:21 Peter_R joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!