00:15 committable6 joined 00:20 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #713 from MoarVM/fsa_valgrind_error_support 00:20
travis-ci.org/MoarVM/MoarVM/builds/296996584 github.com/MoarVM/MoarVM/compare/3...0282af2a98
00:20 travis-ci left
MasterDuke ^^^ just a single github timeout 00:22
jnthn Phew :) 00:26
02:56 ilbot3 joined 04:45 ugexe joined 07:32 domidumont joined 08:02 domidumont joined 08:54 leont joined 09:13 AlexDaniel joined
nine Ok, with disabled eliminate_pointless_gotos optimization and with only ever inlining one callee into a given caller inline_in_place passes the spectests. So there's at least a stable base to continue from. 09:30
The restriction to one inlinee only is due to some handler issue. Apparently a handler goto instruction goes missing otherwise. It's found by merge_graph but later we don't encounter the annotation. 09:31
And that seems to be fixed now? Which surprises me, because I've tried the exact same change before. 09:42
10:05 evalable6 joined
nine The eliminate_pointless_gotos issue seems to be due to an MVM_SPESH_ANN_DEOPT_ALL_INS annotation. It works just fine when I keep gotos with that annotation intact. 10:33
This tells me that the "troubled" goto instruction is the one that replaces the invoke op. Moving the annotation doesn't seem to help so I guess we somehow still need that goto. 10:46
And there are 3 spec tests that fail unless I skip removal of the MVM_SPESH_ANN_INLINE_END annotated goto as well. Which kinda defeats the purpose of inlining in place :/ 10:55
11:01 evalable6 joined
nine And there's t/spec/S02-literals/quoting.t which is the only test still broken by eliminate_pointless_gotos 11:16
Or it may just be a really weird flapper 11:19
11:26 patrickz joined 12:22 patrickz joined
jnthn nine: Rememeber to build/spectest with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 which will really torture out any new issues :) 12:52
nine: Also, in the instruction deletion code, it moves some annotations on delete; may be worth checking if it's doing that here 12:53
nwc10 jnthn: if it's convenient - FSA_SIZE_DEBUG is currently broken (on some compilers) without 12:54
- memcpy(dbg->memory, p + sizeof(MVMuint64), new_bytes > old_bytes ? old_bytes : new_bytes);
+ memcpy(dbg->memory, (char *)p + sizeof(MVMuint64), new_bytes > old_bytes ? old_bytes : new_bytes);
in src/core/fixedsizealloc.c
ie needs that (char *) cast before p, which is void *
(for more torture still) 12:55
jnthn timotimo: ^^
nwc10 :-)
me-- # not figure out who the actual "culprit" was 12:56
jnthn Pretty sure it was timotimo's PR that I merged
13:00 ilmari joined 13:52 patrickz joined
dogbert17 tried to look a bit more at github.com/rakudo/rakudo/issues/1202 14:43
when run under load it always hangs after a while. Attaching gdb to the process reveals nothin, i.e. the 'bt' command is unable to display anything. 14:45
I then tried the pstack command instead and it gives a bit more info 14:46
(No symbols found in /lib/i386-linux-gnu/libm.so.6)
(No symbols found in /lib/i386-linux-gnu/librt.so.1)
(No symbols found in /lib/i386-linux-gnu/libdl.so.2)
(No symbols found in /lib/ld-linux.so.2)
0xb77c4cb0: _fini + 0x31d42c
dunno how to get symbols on those libraries but the presence of '_fini' and some google gives me the impression that the hang occurs when the code is done and the program is exiting 14:48
MasterDuke dogbert17: if you're interested in some new stuff to debug, irclog.perlgeek.de/perl6/2017-11-03#i_15398818 14:49
dogbert17 whether that is a clue is for someone else to decide :)
MasterDuke more background here irclog.perlgeek.de/perl6/2017-11-02#i_15394120 14:50
dogbert17 MasterDuke: looks
is it a module that's crashing? 14:51
MasterDuke: have run the script once so far, no crash on my 32 bit system 14:56
MasterDuke did you edit the script to use MsgPack instead of Data::MessagePack? 14:57
dogbert17 oops 14:59
dogbert17 must improve my reading skills :) 15:00
MasterDuke heh, well the background info is kind of spread around... 15:01
dogbert17 hmm, it seems I need to apt-get something as well 15:02
15:03 domidumont joined
Geth MoarVM: 2f0672f745 | (Zoffix Znet)++ | src/io/syncfile.c
Fix too-late EOF detection on TTY handles

TTY handles aren't seakable so EOF detection on them relies on our
  `eof_reported` flag that currently gets set if we read zero bytes
despite wanting to read more. This causes an issue where a large read that does actually does read some bytes still doesn't set EOF and the code wait until another read of zero bytes to actually set it.
Fix by checking whether we read fewer bytes than we wanted instead.		 15:30
15:44 evalable6 joined 15:45 travis-ci joined
travis-ci MoarVM build passed. Zoffix Znet 'Fix too-late EOF detection on TTY handles 15:45
travis-ci.org/MoarVM/MoarVM/builds/297240208 github.com/MoarVM/MoarVM/compare/a...0672f74523
15:45 travis-ci left
dogbert17 MasterDuke: #0 MVM_panic (exitCode=1, messageFormat=0xb7cb8224 "Invalid owner in item added to GC worklist") at src/core/exceptions.c:682 15:46
#1 0xb7bfdfc9 in gc_mark (tc=0x804c5f8, st=0xa10a2e8, data=0xb4f41e8, worklist=0xa0a5c80) at src/6model/reprs/CStruct.c:623
#2 0xb7bb4076 in MVM_gc_mark_collectable (tc=0x804c5f8, worklist=0xa0a5c80, new_addr=0xb4f41d8) at src/gc/collect.c:428
#3 0xb7bb22e6 in process_worklist (tc=0x804c5f8, worklist=0xa0a5c80, wtp=0xbfffda18, gen=1 '\001') at src/gc/collect.c:342
MasterDuke hm, think that's new 15:47
dogbert17 ran this code: github.com/azawawi/scripts/blob/ma...sgpack.pl6 # had changed to MsgPack ofc 15:48
on the next try I got "Zeroed owner in item added to GC worklist" 15:49
dogbert17 tries valgrind instead 15:51
dogbert17 which will take forever ... 15:52
16:21 zakharyas joined 16:22 domidumont joined
Geth MoarVM: d257df23a9 | (Zoffix Znet)++ | src/io/syncfile.c
Revert "Fix too-late EOF detection on TTY handles"

This reverts commit 2f0672f74523c6ddfe8a216728bbbea8fc7760ce.
  irclog.perlgeek.de/perl6-dev/2017-...i_15401308		 16:29
19:42 evalable6 joined 22:07 colomon joined 23:02 colomon joined 23:56 colomon joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!