|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:42
sena_kun left
00:57
sena_kun joined
02:41
sena_kun left
02:57
sena_kun joined
04:42
sena_kun left
04:56
sena_kun joined
05:40
Voldenet left
05:45
Voldenet joined,
Voldenet left,
Voldenet joined
06:42
sena_kun left
06:57
sena_kun joined
08:42
sena_kun left
08:58
sena_kun joined
09:14
AlexDaniel left,
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
|
|||
| nine | With my frame walker candidate fix, our service has not thrown any frame walker related segfaults so far in several hours of testing! | 10:40 | |
| It does however run into a different segfault eventually: a spesh plugin guard trying to get the type of a NULL object. The spesh plugin is called from JIT compiled code, which makes debugging somewhat tedious. | 10:42 | ||
|
10:42
sena_kun left
|
|||
| nine | But I already found out that the value is the result of the invocation of the &code passed to a Supply's !run-supply-code method. | 10:44 | |
| Or more precicely, it's tc->last_handler_result which gets returned and happens to be NULL | |||
| So far I haven't been able to reproduce this segfault without the JIT | 10:45 | ||
|
10:58
sena_kun joined
11:08
sena_kun left
11:09
sena_kun joined
12:41
sena_kun left
12:56
sena_kun joined
|
|||
| nine | This is odd... the bytecode dump of the code block with the takehandlerresult op is: gist.github.com/niner/9557887cfcd9...5e35c86c65 | 12:57 | |
| There is clearly an unconditional goto right before the takehandlerresult op. But according to rr the takehandlerresult op is executed (setting the result to NULL) | |||
| Ah, ok, that's some magic of how exception handlers work | 13:08 | ||
| So I guess the question is still: where does the NULL come from that ends up in last_handler_result? | 13:10 | ||
|
14:42
sena_kun left
14:58
sena_kun joined,
patrickb joined
|
|||
| nine | I wonder, if the handler writes the result into the wrong frame's return_value | 16:01 | |
| Well at least it's not a regression of my recent work on callbacks. Got a little suspicious because that involved quite a bit of fiddling with returning from frames | 16:15 | ||
| dogbert11 | an old bug then? | 16:19 | |
| nine | Pretty sure about that | 16:24 | |
| dogbert11 | could it be repsonsible for the 'Unwound entire stack but missed handler" errors that we have aplenty? | 16:26 | |
| nine | Hard to say. I think I still know too little | ||
|
16:33
scovit joined
|
|||
| scovit | Hi all, sena_kun on #cro suggests that github.com/croservices/cro/issues/111 might be a MoarVM bug. I am not sure about that and I come here to poke your wisdom | 16:34 | |
| That issues breaks Cro on Mac OSX | |||
| if flush in moarvm is defined as sync, then moarvm is just reflecting different behaviors by different OSs | |||
| and the Log library could just deal with the exception | 16:35 | ||
| instead of giving up and crashing | |||
|
16:41
sena_kun left
16:56
sena_kun joined
|
|||
| nine | I wonder why fsync and not fflush | 17:18 | |
| scovit | fflush is for cached files, fsync is lower level and is a synchronization mechanism | ||
| I was suggesting this on #cro: possibly the solution of the bug is to remove fsync from flush. But then, it can be useful to add it somewhere else (method sync?)and if that fail on MacOS, then let it be. But you might not agree on thisIt ends up to be a choice, in any case | 17:19 | ||
| A fix would be to add ENOTSUP to this list github.com/MoarVM/MoarVM/blob/9ba1...ile.c#L230 | 17:45 | ||
| In my humble opinion this a bit sweeps it under the carpet | 17:46 | ||
| jnthn | Given we already are sweeing syncing something that can't do that under the carpet, I guess we'd just be making the sweeping more portable :) | 17:56 | |
| scovit | jnthn do you want a pull request, or you do it directly? | 18:02 | |
| jnthn | scovit: PR if you've chance; I'm only half here :) | 18:16 | |
| scovit | roger | 18:30 | |
|
18:42
sena_kun left
|
|||
| Geth_ | MoarVM: scovit++ created pull request #1226: Detect files that cannot be synched also on MacOS |
18:45 | |
|
18:54
scovit left
18:57
sena_kun joined
|
|||
| nine | jnthn: anything against me merging maybe_fix_frame_walker_segfaults? It seems to improve things greatly, even if it's not a 100 % correct fix | 19:32 | |
|
19:39
lucasb joined
20:41
sena_kun left
20:55
sena_kun joined
22:41
sena_kun left
22:56
sena_kun joined
22:59
lucasb left
23:36
patrickb left
|
|||