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