|
08:03
tellable6__ joined,
linkable6__ joined
08:05
sourceable6__ joined,
coverable6__ joined,
benchable6__ joined
08:09
linkable6 left,
tellable6 left,
sourceable6 left,
coverable6 left,
benchable6 left
08:25
leont_ joined
08:31
leont left,
leont_ is now known as leont
|
|||
| patrickb | o/ | 12:44 | |
| I've started using the debugserver file loaded notifications with the suspend flag. Whenever I receive such a notification, I do a quick introspection (usually without any debug protocol action) and then resume the thread again. | 12:45 | ||
| But most of the time the threads don't resume and the debug server logs print: "success resuming thread; its status is now 2". Status 2 is MVMGCStatus_UNABLE. | 12:46 | ||
| I suspect the GCStatus handling is somehow broken, but I still have too little of an idea how the GC status' are meant to work to trace the error in a directed manner. Any pointers are highly appreciated... | 12:50 | ||
| I notice that MVM_debugserver_request_thread_suspends moves the GCStatus from NONE -> INTERRUPTED|SUSPEND_REQUEST, while notify_new_file moves it from NONE -> NONE|SUSPEND_REQUEST. Is that difference intentional? | 13:49 | ||
| gc/orchestrate.c signal_one_thread also does not account for NONE|SUSPEND_REQUEST, only for INTERRUPT|SUSPEND_REQUEST. | 14:07 | ||
| I start to suspect again, that NONE|SUSPEND_REQUEST is not a valid status. | 14:08 | ||
|
15:55
[Coke] left
17:49
[Coke] joined
|
|||
| patrickb | I tried getting rid of NONE|SUSPEND_REQUEST by adjusting notify_new_file to behave identical to MVM_debugserver_request_thread_suspends. The first few tries seem promising. | 21:24 | |
| Another question: It seems the context and outer contexts of a thread suspended by notify_new_file does not include the UNIT context of the respective comp unit. | 21:25 | ||
| Is this just fundamentally the case? Is there any chance I can get hold of that unit context? | 21:26 | ||
| timo | when notify_new_file happens, is the frame it's running usually the load or dependencies+deserialize frame from that compunit? | 21:45 | |
| if that's the case, it would stand to reason that some stuff isn't there yet | 21:48 | ||
| or not where we're looking | |||
| patrickb | Maybe to give a little more context, I'm trying to retrieve $?CHECKSUM and $?SOURCE, both of which are set in the unit context (the one that has !UNIT_MARKER set). | 21:56 | |
| lizmat | only with RakuAST | ||
| patrickb | I find none of the three in any outer context | ||
| lizmat | I believe? | ||
| patrickb | lizmat: I've added it to the legacy compiler locally. | 21:57 | |
| lizmat | ah... ok | ||
| so this works: raku -e 'say $?SOURCE' ? | |||
| patrickb | let me try (so far I have only seen it in the debugger) | 21:58 | |
| Yes that works | 21:59 | ||
| lizmat | patrickb: perhaps merge that to rakudo main ? | 22:03 | |
| possibly with a revision check | |||
|
22:04
librasteve_ left
|
|||
| patrickb | yeah... currently I have a hand full of patches in moar, Rakudo and moarvm-remote. I know I need to PR the lot... | 22:05 | |
| timo | one thing i don't like about notify_new_file is that only one thread ever gets stopped; if a second thread encounters the new file for the first time while the first one is still stopped it will just go on its merry way | 22:06 | |
| lizmat | could you gist the rakudo changes, I'll take care of it from there | ||
| timo | what does the stack trace look like of the thread when it's stopped at that point? | 22:07 | |
| i was imagining that the "new file" notification would be a good spot for the debug server client to set up breakpoints | |||
| patrickb | let's see if I cancmanage to retrieve the trace... | 22:08 | |
| timo | should be able to just MVM_dump_backtrace or what it's called | 22:13 | |
| out of gdb | |||
| patrickb | gist.github.com/patrickbkr/aeb443b...f4fac9cf61 | 22:34 | |
| lizmat: github.com/rakudo/rakudo/pull/6091 | 22:39 | ||
| timo | that doesn't look like a new file, maybe at the position it's stopped there's no frame set up yet? do we stop the thread in the bytecode verification step or something? | 22:42 | |
| patrickb | Oof, I don't know off hand... | 22:43 | |