|
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
|
|||