github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
Geth | MoarVM/master: 4 commits pushed by ZhongnianTao++, (Samantha McVey)++ | 08:10 | |
13:20
lucasb joined
|
|||
Geth | MoarVM: d24f6952b3 | (Deven T. Corzine)++ | 3rdparty/dyncall Use updated dyncall library with "execstack" fix. The following bugs relate to the "execstack" flag being set on MoarVM, even though executable stacks weren't actually needed: github.com/MoarVM/MoarVM/issues/470 github.com/MoarVM/MoarVM/issues/794 ... (18 more lines) |
13:55 | |
MoarVM: e54cf70d18 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/dyncall Merge pull request #1157 from deven/execstack Use updated dyncall library with "execstack" fix. |
|||
13:55
Kaiepi left
14:46
brrt joined
|
|||
brrt | \o | 15:32 | |
Geth | MoarVM: samcv assigned to ZhongnianTao Issue gb2313 clang warnings github.com/MoarVM/MoarVM/issues/1163 samcv self-assigned gb2313 clang warnings github.com/MoarVM/MoarVM/issues/1163 Jit some num ops |
15:41 | |
15:53
Kaiepi joined
16:18
brrt left
|
|||
nwc10 | o/ | 16:20 | |
dogbert17 | hi nwc10 | 16:35 | |
not very much happening here atm it seems | |||
interesting, two, seemingly unrelated, bug reports crashes in the exact same place | 16:44 | ||
M#3114 and M#3115 | 16:45 | ||
hmm | 16:48 | ||
16:51
brrt joined
17:00
pamplemousse joined
17:22
bisectable6 left,
evalable6 left
17:23
pamplemousse left,
bisectable6 joined
17:26
evalable6 joined
17:29
committable6 left
17:30
chloekek joined
17:31
committable6 joined
17:48
domidumont joined
18:23
brrt left
|
|||
Kaiepi | there's this weird bug in the code i'm working on that doesn't seem to be related to what i'm doing | 18:26 | |
you can initialize an async udp socket just fine and create an MVMOSHandle repr for it, but when you try passing it to MVM_io_socket_async_write_bytes_to, it ends up with a zeroed out struct instead | 18:27 | ||
i'm pretty sure i'm not overwriting it myself | 18:28 | ||
timotimo | have you ever tried rr? | 18:32 | |
it's possible that you're forgetting to mark the pointer to the MVMOSHandle | 18:33 | ||
and the GC is clearing out the memory where the struct used to live | |||
and the pointer you're following is out of date | |||
just a theory | |||
18:46
bisectable6 left
18:51
bisectable6 joined
|
|||
Kaiepi | rr timotimo? | 18:51 | |
timotimo | yeah, it lets you play your program execution backwards | 18:52 | |
which is a good combination with watchpoints | |||
but i guess if your situation is easy to reproduce, you don't have to debug backwards | |||
you can just set the watchpoint as soon as the MVMOSHandle is created i guess | 18:53 | ||
19:44
pamplemousse joined
20:40
domidumont left
|
|||
dogbert17 | .seen timotimo | 20:51 | |
tellable6 | dogbert17, I saw timotimo 2019-08-25T20:12:01Z in #perl6: <timotimo> *shruuuuug* | ||
20:53
AlexDaniel left
20:54
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
|
|||
dogbert17 | any c-hackers around? | 21:11 | |
AlexDaniel | dogbert17: ehhhā¦ what's the question? | 21:23 | |
dogbert17 | a stupid question really. Look at this function github.com/MoarVM/MoarVM/blob/mast...ine.c#L191 | 21:46 | |
the function is supposed to return an MVMint32 but the last line is 'return (MVMuint32)result;'. Why? | 21:47 | ||
AlexDaniel squints | 21:49 | ||
jnthn | dogbert17: Hm, that return type should probably be MVMuint32; there's even code there to ensrue it can't be negative. | ||
dogbert17 | aha | ||
I just reported that I belive there's a bug in the commit which introduced that function. Perhaps the return type is the problem. | 21:50 | ||
*believe | |||
AlexDaniel | looking at what calls it, it's uint throughout, so yeah, seems like a typo | 21:51 | |
dogbert17 | AlexDaniel: I suspect that this commit, github.com/MoarVM/MoarVM/commit/50...22c21f13b, is 'partly' responsble for M#3114 | 21:52 | |
AlexDaniel | dogbert17: nah I doubt the return type is the cause | 21:53 | |
jnthn | dogbert17: Unfortunately, only in so far as it permits more inlining. | ||
dogbert17: Meaning it just exposed something that could have happened differently anyway. | |||
releasable6: status | 21:54 | ||
releasable6 | jnthn, Next release in ā26 days and ā21 hours. R6 is down. At least 7 blockers. Unknown changelog format | ||
jnthn, Details: gist.github.com/9d95b02ac7e8659e71...68bd103f8b | |||
jnthn | Ah, no immediate stress to hunt it down :) | ||
AlexDaniel | jnthn: we were aiming at 1st of September, but I don't know if that's happening | ||
dogbert17 | ok, still I'm quite certain that the commit introduced a SEGV | ||
AlexDaniel | well, it's unlikely to happen, because I don't feel like doing release prep this weekā¦ | 21:55 | |
jnthn | Ah, and this issue is already in the blocker list | 21:56 | |
So I can find it when glancing at those | |||
dogbert17 | that's AlexDaniels fault :-) | ||
jnthn | It's convenient, it's one less thing I have to separately remember :) | ||
AlexDaniel | yeah, I marked it, because pure perl6 code causing a segfault is a big no-no in my book | ||
especially at the size of that gist | 21:57 | ||
but I didn't know at the time it was a regression that we missed :) | |||
at some point I used to write scripts with segfaults in mind, i.e. a loop that simply restarts everything and the program picks up the work from where it was dropped on the floor | 21:59 | ||
dogbert17 | the SEGV happens here: github.com/MoarVM/MoarVM/blob/mast...rp.c#L3988 | ||
AlexDaniel | I don't do that anymore because rakudo no longer does that as often | 22:00 | |
dogbert17 | it's definitely getting very hard to find bugs in MoarVM :) | ||
AlexDaniel | actually, pretty much never for scripts that I haveā¦ but that gist by jmerelo is really bad :D | 22:01 | |
dogbert17 | there's another SEGV that fails on the exact same line | 22:02 | |
AlexDaniel | dogbert17: well, previously bugs used to find me :) Stuff like this ticket: github.com/perl6/whateverable/issues/24 | 22:03 | |
in 3 days it'll be one year with no updates on that ticket, i.e. no new issues | 22:04 | ||
bisectable6: uptime | |||
bisectable6 | AlexDaniel, 3 hours, 18 minutes, and 6 seconds, 218.886719MiB maxrss. This is Rakudo version 2019.07.1-94-gd1f9d2848 built on MoarVM version 2019.07.1-50-gb614a7b4d implementing Perl 6.d. | ||
AlexDaniel | and that's on almost the latest rakudo version :) | ||
dogbert17: btw we should point some static program analyzer on moarvm's code | 22:07 | ||
dogbert17: I'd expect it to find issues like the one you mentioned | |||
dogbert17 | I run cppcheck from time to time | 22:08 | |
MasterDuke | AlexDaniel: one (some?) are already run, but not everybody has access to the output | ||
AlexDaniel | MasterDuke: I see | ||
MasterDuke | i don't remember which one it is. coverity maybe? i think timotimo knows | ||
dogbert17 | it's coverity | 22:09 | |
timotimo | yes | ||
scan.coverity.com/projects/paultco...b=overview | |||
MasterDuke | what's the one that occasionally does free scans on FOSS software and posts writups? something like viva64 maybe? or does it start with a 'p'? | 22:10 | |
AlexDaniel | looks like you can also get pvs-studio for one year: www.viva64.com/en/open-source-license/ | ||
MasterDuke | ah, that's what i was thinking of | ||
AlexDaniel | MasterDuke: that's pvs-studio | ||
dogbert17 | it looks as if the last scan was done in May last year ... | 22:12 | |
22:12
chloekek left
|
|||
MasterDuke | while people are around, github.com/MoarVM/MoarVM/pull/1162 is pretty simple, anyone mind if i merge it? | 22:14 | |
AlexDaniel | MasterDuke: this stuff makes me wonder why it wasn't done before | 22:17 | |
MasterDuke: also, if you merge now I'll bump right away | |||
:) | |||
MoarVM: a9b44444dd | MasterDuke17++ (committed using GitHub Web editor) | src/jit/graph.c Merge pull request #1162 from MasterDuke17/jit_some_num_ops Jit some num ops |
|||
MasterDuke | yeah, i was a little surprised | 22:18 | |
AlexDaniel | wow, what a sha | ||
jnthn | Just glanced over it; it was indeed an easier review than I expected. :) | 22:19 | |
rest time o/ | |||
22:34
pamplemousse left
23:09
lucasb left
23:52
Kaiepi left
|