github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:09 reportable6 left, reportable6 joined 02:47 ggoebel left 04:50 Kaiepi left 04:57 Kaiepi joined 07:13 squashable6 left 07:16 squashable6 joined 09:01 sena_kun joined 09:58 ilogger2 joined 10:21 brrt joined
brrt \o 10:23
what, nobody shouting at me for broken sp_bind_o 10:25
10:34 brrt left
nwc10 .tell brrt o/ 10:48
tellable6 nwc10, I'll pass your message to brrt
Geth MoarVM: c61236f96e | (Stefan Seifert)++ | 13 files
Fix access to freed memory in resolve_using_guards

Commit acb04a448bd7b067f1a0943b6fd521e21057c96e fixed outdated pointers in the guard set, but it was still possible that the guard set was freed while still in use by resolve_using_guards as the next GC safe point may occur in evaluate_guards. Fix this by turning SpeshPluginState into a 6model object, so we can let the GC figure out whether the state is still in use somewhere or not
11:15
nine .tell jnthn I just merged my fix for the spesh plugin guards. It clearly fixes 2 bugs and I've been running rakudo with the fix for a couple of weeks when investigating and developing. I'm confident that we're better off with it than without it and you can still have a look later on. 11:17
tellable6 nine, I'll pass your message to jnthn
12:44 lucasb joined 13:37 domidumont joined 14:13 ZzZombo_ joined, ZzZombo_ is now known as ZzZombo 14:14 brrt joined 14:25 Kaiepi joined 14:31 brrt left 14:37 Kaiepi left 14:38 Kaiepi joined 14:39 Kaiepi left, Kaiepi joined 14:40 ggoebel joined 14:48 domidumont left 14:52 Altai-man_ joined
Geth MoarVM: ugexe++ created pull request #1201:
Avoid using preprocessor inside MVMROOT
16:10
16:49 Altai-man_ left
nine Do we already know that commit 27dcb378ef4236b4f7394eef3926cb652ba2186a (Revert "The exprjit of sp_bind_o caused wrongness") causes MoarVM panic: Adding pointer 0xda62b0 to past fromspace to GC worklist? 19:06
Geth MoarVM: 0f0e6d3a27 | (Stefan Seifert)++ | src/spesh/plugin.c
Work around MSVC not coping well with preprocessor instructions inside an MVMROOT

Fixes GH #1200
19:07
19:08 Kaiepi left 19:11 Kaiepi joined 19:30 travis-ci joined
travis-ci MoarVM build errored. Stefan Seifert 'Work around MSVC not coping well with preprocessor instructions inside an MVMROOT 19:30
travis-ci.org/MoarVM/MoarVM/builds/600420332 github.com/MoarVM/MoarVM/compare/c...0e6d3a27c0
19:30 travis-ci left 20:37 brrt joined 20:49 Kaiepi left 20:50 Kaiepi joined
brrt .tell nine, yes we do 20:57
tellable6 brrt, No! It wasn't me! It was the one-armed man! Backtrace: gist.github.com/dd6c50fc1eb93a0b8d...ff731cadc6
brrt i'm working on it
21:03 sena_kun joined
AlexDaniel timotimo: hello! 21:05
Geth MoarVM: ugexe++ created pull request #1202:
Fix obscure deadlock
brrt I also know the problem isn't actually in sp_bind_o 21:08
Geth MoarVM: b0b3fc8c5a | (Nick Logan)++ (committed using GitHub Web editor) | src/gc/orchestrate.c
Fix obscure deadlock
21:11
MoarVM: 89aa45f561 | niner++ (committed using GitHub Web editor) | src/gc/orchestrate.c
Merge pull request #1202 from ugexe/patch-21

Fix obscure deadlock
It doesn't make the least bit of sense that this fixes anything. Alas I can't find any downside to this change either and it even saves a tiny bit of useless work when there are no subscribers. So let's take what we can get... Thanks for looking into this!
21:13 tellable6 joined
AlexDaniel brrt: can you try that again for me please? 21:16
21:16 ggoebel left
brrt AlexDaniel: what exactly? 21:18
tellable6 2019-10-20T10:48:10Z #moarvm <nwc10> brrt o/
AlexDaniel .tell nine, test test
tellable6 AlexDaniel, I'll pass your message to nine
AlexDaniel ok, it works now :)
timotimo nine: but how?!? HOW??!?!?!!
AlexDaniel timotimo: how what? 21:19
timotimo: that moarvm fix?
if you're really curious, I guess looking at what the compiler spews out can help 21:20
it's hard to tell what happens with that assignment there
could it be that start_time and end_time end up being the same value? would that cause a deadlock? 21:21
brrt yeah, that commit message was one that could've done with a bit more explanation :-D 21:22
timotimo um
it's literally just being put into a struct
21:23 sena_kun left
AlexDaniel no, the difference between start_time and end_time is put into a struct 21:24
so depending on when you actually call this thing that has nanosecond precision you can get slightly different behavior
what would cause a deadlock? Let's say end_time is one nanosecond smaller than start_time (somehow!), would it wrap around then, and if so, can it cause a deadlock? 21:26
I see no way for the compiler to reorder the code that much, so it's unlikely, of course, but at least that kinda sorta makes sense in some other world :) 21:27
but then, start_time being equal to end_time is far less unlikely 21:28
what's the real precision of uv_hrtime on windows?
22:18 brrt left 22:54 lucasb left
timotimo the number is literally just put into -actually- a VMArray, and the VMArray is then plopped into a queue ... except the problem also occurs when the code inside the if statement isn't running at all. 23:17
AlexDaniel oh 23:21
23:59 Kaiepi left, Kaiepi joined