github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
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
Geth_ MoarVM: scovit++ created pull request #1226:
Detect files that cannot be synched also on MacOS
18:45
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