02:56 vendethiel joined 03:36 allbery joined, geekosaur joined 04:02 ggoebel16 joined 05:49 geekosaur joined 05:56 geekosaur joined 06:40 mojca joined 07:39 domidumont joined 07:44 domidumont joined 07:56 FROGGS[mobile] joined 07:58 vendethiel joined 08:38 FROGGS joined 09:05 FROGGS joined 09:31 FROGGS joined 10:02 mojca joined
timotimo i think i'll go ahead with the "set debug name" thing for the STable 12:33
then we'll also have better naming for the guards in spesh candidates 12:34
i expect it'll be more useful to have that as a char* rather than an MVMString 12:35
jnthn timotimo: Yeah, that was by plan 12:36
nqp::setdebugtypename($obj_o, $name_s) (evalutes to $obj_o) 12:37
Where we attach it to the STABLE($obj_o)
I'll be heap snapshot hacking a little later today, all being well :)
timotimo fantastic :) 12:38
is nqp::getdebugname necessary? 12:42
jnthn Don't immediately see a need 12:48
You can .^name in Perl 6 space
Or NQP
timotimo right
hmpf. if we want to use that in nqp itself, we'll be bumping the stage0 again 12:54
jnthn Let's just in Rakudo for now :)
But yeah, you're right
timotimo the clever of the day: not incrementing cur_op before goto NEXT 12:58
jnthn such smart
very brain
wow
mst hah
I had basically that overnight, had a 'first op to resume from' special pointer for a sort of continuation-ish thing 12:59
then forgot to clear it so it just kept re-running the first op forever
jnthn goes to nom lunch :)
timotimo good nom! 13:05
2 argument guards 13:06
type(0, 0x81ff10)H<8B>v^XH^O<BF>F^Bf<83><F8><FF>t/H<8B>^QE^O<B7><C9>H<85><D2>H^OD<D1>H<8B>N^X^O<B7>^DAH<8B>^T^BH<8B>r^PH<8D>J^XH<8B>F^PH<8B><80><B8>
^- seems like i might want to null that slot :)
well, i am nulling the debug_name, but it's still giving me garbage in the debug output there. huh. 13:11
oh, heh, that may want to be serialized :) 13:12
huh. i don't see a serialization/deserialization pair for char * data 13:27
so it'd have to go through the string heap? :\ 13:28
nine ('META6.json', 'META.info').map({$.prefix.parent.child($_)}).first($_.f) 13:38
timotimo i notice i'm not very thoroughly good at serialization code 13:55
ah, seems like i +='d the cur_write_offset, rather than the *cur_write_offset 13:56
jnthn timotimo: I'd expect that you could add write_cstring and read_cstring APIs 13:59
To the serializer
timotimo aye
jnthn That use strlen on write
timotimo i've done just that
jnthn Then just make sure on read you do the correct stuff with ensure_can_read or so to not let a corrupt serialization blob cause out of bounds access 14:00
timotimo aye
jnthn So...how is heap snapshotter formed... 14:02
timotimo pro tip: return the string buffer from the "read a cstring function" 14:04
seems like --asan is busted 14:18
==1350==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
outputting c strings with %d for fprintf is a pretty great idea 14:21
jnthn encrypted-tbn0.gstatic.com/images?...9fnvXU4m4w 14:33
timotimo very 14:35
14:38 FROGGS[mobile] joined
timotimo i don't know why i still get mostly binary garbage :| 14:40
am i forgetting to set the debug_name pointer somewhere? must be something like that 14:44
or maybe this is about lazy deserialization?
out of nowhere (as far as i can tell) the value 0x7f87837613c0 comes into existance in that slot 14:45
jnthn Odd...I'd think we zero the STable 14:46
Where did you add the new value? At the end?
timotimo before deserialize_repr_data 14:47
let me push to a branch
FROGGS[mobile]
.oO( master is a branch too )
jnthn If you don't put it at the end, and you didn't recompile Rakudo's ext ops, you could land up in trouble.
timotimo i'll remove some debug spam first, though 14:49
dalek arVM/setdebugtypename: 0f7ea20 | timotimo++ | tools/moar-gdb.py:
Merge branch 'moar-gdb.py-python3'

This ports moar-gdb.py to python 3, which is what the latest GDB versions ship with. There's still some strange behaviours, but there's no good reason to keep this in a branch at this point.		 14:52
arVM/setdebugtypename: 4c01c3a | timotimo++ | / (9 files):
add "debug_name" field to STable struct and setdebugtypename
timotimo oops
that first commit was supposed to be on the main branch already 14:53
but it seems like it didn't end up there yet
i wouldn't put it past me to just completely have forgotten how even to C for this commit 14:57
but i do get the values out of the serialized blob correctly, at least the values get debug-printed on the read_cstr end 14:58
timotimo is blocking 15:10
jnthn runs timotimo on node.js 15:12
timotimo asynchronlizes
jnthn + } else { + st->debug_name = 0; + } 15:14
Would be better as NULL there
+ st->debug_name = NULL; 15:15
That shouldn't be needed as we allocate zeroed memory
I can't see anything else wrong...
timotimo hmm 15:16
so why would these values end up in the STable? :\ 15:17
those are obviously kind-of-valid pointers
0x7f1092a7a170, 0x7f1092a5ddc0, 0x7f1092a693b0 ...
and reading from all those addresses also works fine, because it doesn't segfault
it's just bogus data, and in a totally different region from what malloc gives me when i allocate the buffers to hold these strings 15:18
i've also got SERIALIZATION_LAZY set to 0 locally and that doesn't change a thing
jnthn timotimo: You did rebuild Rakudo after changing the STable structure, yes? 15:19
So it's not extops etc.?
timotimo aye 15:20
i'll do it again
does it give bad output for you when you have a spesh dump active? 15:22
jnthn I didn't try building it, sorry
(a bunch of local diffs and stuff with profiler)
timotimo ah, ok 15:23
that's fine
jnthn Just read the diff
timotimo i'm glad it looks sane
jnthn Yeah...if you don't store the string you get back at all when deserializing, do they still end up with junk?
timotimo not at all, or store 0 instead? 15:24
jnthn Not at all 15:25
STable memroy should be all zero at initialization
15:26 pyrimidi_ joined
timotimo but guard->match is supposed to be a type object that has a STABLE we can introspect, right? 15:27
jnthn Uh, I think guard->match is directly pointing to an STable? 15:28
timotimo still junk 15:30
oh, it is?
let's see.
jnthn It may well we, to avoid a deference on every match
timotimo i see 15:31
jnthn *be
timotimo YES! 15:33
you're my saviour of the day! :)
i've decided to not use the version of assignment to the stable that would cause repossession 15:35
is that fine?
i mean, for setting the debug typename
jnthn timotimo: Yeah, I think so
timotimo: 'cus I suspect we'll put the name in place really early 15:36
dalek arVM/heap-profiler: 39e9841 | jnthn++ | src/ (5 files):
Refactor to prepare for multiple profilers.

Move most of the logic in profile.c over to instrument.c, which is now the overall implementation of the instrumenting profiler. profile.c will become the thing that dispatches to the various other profilers.
arVM/heap-profiler: 5251c98 | jnthn++ | src/ (4 files):
Test for kind of profiling to do.
timotimo i'm not sure, though, why it doesn't actually show up in the spesh log anywhere 15:37
maybe i'm not looking hard enough, though
ah, it does show up in some places 15:39
very good!
hm. it never shows any of them for type guards, though 15:41
i wonder if those types we're guarding against never have the debug name set, or if it's a brokenness
ah! it does show up in some places 15:43
very, very good.
dalek arVM/setdebugtypename: 14ae31e | timotimo++ | src/ (3 files):
setdebugtypename now works properly, also in the spesh log.
 15:44
timotimo i'll run a spectest with this
jnthn timotimo++
timotimo spec tests pass, unsurprisingly, so i think i'll merge 15:54
unless you have something against that, that is 15:55
jnthn Go for it
timotimo excellent
jnthn Remember to bump MOAR_REVISION before pimping out NQP with setdebugname
And similar before doing Rakudo
This will be really cool for our spesh logs as well as the heap profiler! :D 15:56
dalek arVM: 6e5f50a | timotimo++ | tools/moar-gdb.py:
a whole bunch of changes and debug spam for moar-gdb.py

currently can't analyze the gen2 :(
arVM: 4263b71 | timotimo++ | tools/moar-gdb.py:
[moar-gdb.py] fix up lots of more stuff for py3 and such
arVM: 6df338e | timotimo++ | tools/moar-gdb.py:
[moar-gdb.py] throw out "reached" crutch
MoarVM: 0f7ea20 | timotimo++ | tools/moar-gdb.py:
timotimo oh
yes, yes.
all done 15:58
moritz timotimo++
timotimo \o/
jnthn Nice 15:59
timotimo the profiler will want to know about this, as well, then.
at least i suspect so 16:00
see you in ~2.5h, i'll drive home now 16:06
jnthn Safe drive o/ 16:10
16:13 mtj_ joined 16:16 FROGGS joined
dalek arVM/heap-profiler: 8b45f42 | jnthn++ | src/ (5 files):
Stub in various heap profiler API functions.

This wires up the snapshot taking to the GC, and gets us starting and ending the heap profiling. Not collecting any interesting data yet.		 16:26
FROGGS uhh, No registered operation handler for 'setdebugtypename' 16:30
jnthn FROGGS: There was an NQP_REVISION bump; did you miss rebuilding? 16:31
FROGGS ohh, indeed
16:41 FROGGS[mobile] joined
dalek arVM/heap-profiler: e8fc9e3 | jnthn++ | src/ (13 files):
Register all perm roots with a description.

This will be used by the heap profiler, but may also be useful when debugging.		 17:05
arVM/heap-profiler: 40f536f | jnthn++ | src/profiler/heapsnapshot.h:
We'll need some more node types for roots.
 17:12
jnthn Well, there's the groundwork done. I guess The Hard Bit comes next... :-) 17:16
But, enough for today, I think :) 17:19
17:24 zakharyas joined
timotimo drive was strenuous but okay 19:56
moritz \o 20:06
20:21 FROGGS[tab] 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!