timo ugghhhh the crash doesn't reproduce 00:08
Geth rakudo/windows_latest_azure_pipeline: d69f2790d0 | (Timo Paulssen)++ | azure-pipelines.yml
get freshest moarvm change
00:17
rakudo/windows_latest_azure_pipeline: 962d5a6c4e | (Timo Paulssen)++ | azure-pipelines.yml
previous commit hash was wrong
00:22
rakudo/windows_latest_azure_pipeline: 5e5ccbd27e | (Timo Paulssen)++ | azure-pipelines.yml
even newer moar commit
00:31
rakudo/windows_latest_azure_pipeline: c2d395c9d8 | (Timo Paulssen)++ | azure-pipelines.yml
remove debugging stuff for one try?
01:10
rakudo/windows_latest_azure_pipeline: f9795ecd77 | (Timo Paulssen)++ | azure-pipelines.yml
turn procdump back on
01:26
rakudo/windows_latest_azure_pipeline: 291f125999 | (Timo Paulssen)++ | azure-pipelines.yml
moar bump
01:42
rakudo/windows_latest_azure_pipeline: b62b8a09c9 | (Timo Paulssen)++ | azure-pipelines.yml
try other way of procdump again
01:59
rakudo/windows_latest_azure_pipeline: 37325d4ee1 | (Timo Paulssen)++ | azure-pipelines.yml
bump moar
02:31
rakudo/windows_latest_azure_pipeline: 8702cbc511 | (Timo Paulssen)++ | azure-pipelines.yml
try building without mimalloc as well
02:33
rakudo/windows_latest_azure_pipeline: 4478a4b2eb | (Timo Paulssen)++ | azure-pipelines.yml
fix typo
[Coke] timo++ 02:34
Geth rakudo/windows_latest_azure_pipeline: de01bd42f7 | (Timo Paulssen)++ | azure-pipelines.yml
no telemeh with --no-mimalloc for now
02:44
rakudo/windows_latest_azure_pipeline: a46891fe5b | (Timo Paulssen)++ | azure-pipelines.yml
grab newer moar
03:08
timo [Coke]: this is incredibly tedious and infuriating :( 03:13
Geth rakudo/windows_latest_azure_pipeline: 34a8a7d39e | (Timo Paulssen)++ | azure-pipelines.yml
get freshest of moars
04:20
timo the solution was, as it so often is, to stub out the windows-related bit (just a single function call), compile to linux, then run it under valgrind to find your very dumb mistake 04:39
ok, still crashy though, just not immediately 04:52
so the place we're exploding is when we have just created a container from %cont_info<container_base> in World.nqp line 1882 in method "build_container" where we try to assign the descriptor to the $!descriptor attribute, and it's an array[str] rather than a P6Opaque-repred thing, so it doesn't have the capability to hold attributes, and that's where the exception flies. it's directly inside a 05:53
"try" though so it shouldn't be a problem at all, but we happen to be inside jitted code and we can't jump back into the interpreter because we don't have correct unwind information installed for the frame we've jitted
Geth rakudo/windows_latest_azure_pipeline: 103 commits pushed by (Timo Paulssen)++
review: github.com/rakudo/rakudo/compare/3...5e8f847eb1
10:01
rakudo/windows_latest_azure_pipeline: 83ba990058 | (Timo Paulssen)++ | azure-pipelines.yml
after the rebase, get appropriate nqp version again
rakudo/main: 00a09d92e6 | (Elizabeth Mattijsen)++ | src/core.c/IO/CatHandle.rakumod
Re-imagine IO::CatHandle internals

  - use less NQP, and normal object construction
  - use an iterator on the slurpy array to get net handle
  - allows for lazy lists of files to read
Fixes #2796
10:02
roast: 0f005e842c | (Elizabeth Mattijsen)++ | S32-io/io-cathandle.t
Add test for #2796
timo the exception handlers we generate for "try" in nqp look like they could be a lot better and smaller 14:49
i'm looking at the one that would be invoked at the time of the latest crashing, but i think they all look similar to this one 14:50
World.nqp, cuuid 281 (Frame_135): checkarity, paramnamesused, exception, getexcategory, hllboxtype_i, box_i, set, decont, dispatch_i nqp-intify, const_i64_16, band_i, hllboxtype_i, box_i, set, unless_i, wval, set, return_o 14:51
i wonder if a mechanism based on dispatchers could be used here? 14:52
anyway, so the code is getting the exception category from the "current" exception, boxes it to an int, deconts and then nqp-intifies that box, ands it with 1, boxes the result, checks if the result is true or not, and then returns either the boxed result integer, or whatever's in wval 2, 44 ... maybe NQPMu? 14:54
normally i'd say "spesh will turn this into very optimized code", but if we generate a load of these, the original code size becomes more important
getexcategory is called nqp::getextype in nqp 14:56
i think the code gen happens in QASTOperationsMAST.nqp in nqp's src/vm/moar/
so a `try 5` in nqp turns into nqp::handle(IVal(5), 'CATCH', WVal(NQPMu)) 15:00
it feels like we should be able to do a little bit better than to compile a full block? 15:05
maybe we can keep a single "handle CATCH and return NQPMu" block for the whole CompUnit 15:08
not seeing any success so far, maybe someone who knows their way around the mast compiler internals and knows how handlers, blocks, gotos, handlerresult, etc interact can figure this out more easily? :) 16:15
hm, for a "super simple" case of handles, there may not even want to be a block in the first place 16:17
seeing some success now :3 16:32
ab5tract timo: nice! Keep on trucking :D 17:00
timo funny, the same spot i've been looking at is now a problem here as well, in that it seems to infinitely loop on itself. the exception handler seems to jump to before the instruction that causes the exception, even though the code where i generate the code and the handler scope look correct? 17:02
hmm. the jit_return_address is set by jit_code_set_current_position, but we longjmp into the interpreter, execute jit_enter, where we take the entry label 17:39
i'm guessing that i'm tickling a case that the jit has never seen so far? 17:44
and/or i'm unaware of some assumption
timo activates the brrt-signal 17:45
so until now, the exception was causing an invocation, but now it's an inside-same-frame goto, and that's not causing the position that the jit is entering the code at to change 18:06
24 frames disappear from World.moarvm's dump output with this change; from 350 to 326. total lines in the dump output go from 45777 down to 44918 18:10
364K after the change, 368K before. not a huge difference, but i'd take it 18:11
the other files don't trigger the optimization much at all, unfortunately 18:13
and raku doesn't at all, though I haven't looked at the QAST of different instances of nqp::handle in there
looks like "try 5" also has code there to set $! to a value, and i'm explicitly only allowing CATCH -> Stmts -> WVal 18:18
i'm not sure under what circumstances we really do have to create a full non-inlined block for the handler(s) 18:33