| 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 | |||
|
09:20
sena_kun joined
09:43
lizmat left
09:44
lizmat joined
10:00
Geth left,
Geth joined
|
|||
| 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 | ||
|
23:56
sena_kun left
|
|||