|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:01
ggoebel joined
00:03
MasterDuke joined,
MasterDuke left,
MasterDuke joined
00:06
lucasb left
00:32
Kaiepi left
01:00
ggoebel left
02:27
Kaiepi joined
02:39
TimToady left
02:40
TimToady joined
|
|||
| ugexe | gist.github.com/ugexe/2fa62c2d498f...47e4a231aa when passed an argument of 1000: perl5: 30s -- perl6: I just killed it at 11 minutes | 04:26 | |
| i guess that could just be the number operations though. i was thinking the labeled loop somehow didnt get optimized based on nothing | 04:31 | ||
| ah of course. Rats | 04:33 | ||
|
07:02
domidumont joined
07:21
robertle joined,
zakharyas joined
08:05
Xliff left
|
|||
| timotimo | ugexe: it could also be that it repeatedly has to coerce the IntStr in @ARGV[0] to a Real to compare it against $numbers_found | 08:25 | |
|
10:10
domidumont left
10:34
lizmat left
|
|||
| nwc10 | good *, #moarvm | 10:55 | |
| moritz | \o nwc10 | 11:01 | |
| timotimo | o/ | 11:09 | |
|
11:26
zakharyas left
|
|||
| Guest16965 | timotimo: the profiler and ugexe's polyglot code, gist above, are not friends ... | 11:53 | |
| timotimo | interesting | 11:55 | |
| i should check it out | |||
| Guest16965 | the files either get very large or there's a SEGV | 11:57 | |
| timotimo | looks like there's something exponentially growing perhaps | 12:01 | |
| did you try un-ratting the code before profiling? | |||
| i wonder if "next"-ing an outer loop confuses the profiler's call graph tracking code | 12:03 | ||
| that'd be similar to that "return with throwpayloadlex from an inlined thingie" problem that may or may not still exist ... | 12:04 | ||
| also, yeah, that program calls int parsing code, like, a whole lot | 12:05 | ||
| Guest16965 | un-ratting the code ? | 12:06 | |
| using ints instead you mean? | 12:07 | ||
| timotimo | yeah | ||
| Guest16965 | I could try | ||
| timotimo | also, turning @ARGV[0] into an int once rather than having it be checked over and over again would also be worth a lot | ||
| like, the sub "val" is responsible for about 50% of total run time in my run | 12:08 | ||
|
12:11
AlexDaniel` left
12:12
Garland_g[m] left
12:15
domidumont joined
12:33
ggoebel joined
12:58
zakharyas joined
13:33
lucasb joined
|
|||
| Guest16965 | un-ratting the code brings execution time down to 38s on my system | 13:38 | |
| ugexe | nan, nanorinf, mod_i, and neg_i are not in the expr jit if someone wants to try what I (think) might be easy-ish to implement | 14:51 | |
| nan should be particularly easy | 14:52 | ||
| you can test the op by running the polyglot gist from earlier with an argument of 300 | 14:54 | ||
|
15:02
brrt joined
15:11
domidumont left
15:19
brrt left
|
|||
| timotimo | ugexe: is there a way to unrat it without losing the polyglotness? also, can you intify the passed argument explicitly so it doesn't have to call val on it repeatedly? | 15:35 | |
|
16:11
robertle left
|
|||
| ugexe | intify the argument sure, since its just +@ARGV[0]. i'm not sure how to unrat it without creating a separate code path/subroutine for perl6 to take (which I try to avoid) | 16:18 | |
|
16:42
zakharyas left
16:45
dogbert17 joined
16:46
brrt joined
|
|||
| timotimo | OK | 16:53 | |
| perl5 doesn't have "div" as infix operator, i guess? | |||
| oh, but you could put floor( ... ) around these divisions | 16:54 | ||
| a Sufficiently Smart Compiler would figure out that's a no-op | |||
| because there's the divisibility check right in front :D | |||
| ugexe | the compiler is so smart it knows no to do that for reasons we cannot fathom | 16:55 | |
| dont forget you've suggested floor(...) before :P | 16:57 | ||
| timotimo | i have? | 16:58 | |
| ugexe | we ended up creating that special version of `sub int` instead which was less than ideal | ||
| timotimo | oh geez | ||
| ugexe | originally it was like `(split(/"."/, "$number))[0]"` or some such when you suggesed floor | 16:59 | |
| timotimo | oooh | ||
|
17:54
robertle joined
18:11
brrt left
19:30
brrt joined
19:31
brrt left
19:35
brrt joined
20:04
zakharyas joined
20:17
lizmat joined
|
|||
| MasterDuke | timotimo: ugexe's polyglot levenshtein-damerau code also created crazy huge profiles | 20:18 | |
| timotimo | oh geez :( | 20:19 | |
| brrt | ohai | 20:29 | |
| MasterDuke | what's the systemd command to look at core dumps? | 20:36 | |
| ah, coredumpctl | 20:38 | ||
| weird, `coredumpctl debug` actually runs the thing that coredumped in gdb? i thought it just opened gdb with the core file | 20:40 | ||
| jnthn | (crazy huge profile) I also tried to do one of that code and it came out giant :) | 20:44 | |
| MasterDuke | hm, my coredumps don't seem to have any symbols at all (e.g., lots of `#0 0x00007fe0bf9feafc in ?? ()`). i should get the same info as when running in gdb normally, right? | 20:47 | |
|
20:48
zakharyas left
|
|||
| jnthn | MasterDuke: I'd expect so, unless you're looking at JIT'd code. Though I think I invoked gdb with it manually, passing the path to moar also | 20:48 | |
| Also I don't know how the new executable frontend interacts with these things | 20:49 | ||
| (If you were using that, that is) | |||
| timotimo | you mean the relocateable launcher? | ||
| i found i might have to rebuild stuff in rakudo's folder now when i've changed moar | 20:50 | ||
| jnthn | timotimo: yes, that | ||
| Hmm...I thought it'd dynamically load libmoar... | 20:51 | ||
| timotimo | aye, i changed it too much and it asploded :D | ||
| maybe related to linking zlib for my debug output for the heap snapshot profiler | |||
| MasterDuke | jnthn: i don't think it would be jitted, it was a small one-liner | 20:57 | |
| got a `corrupted double-linked list` before the most recent coredump | |||
| i'm trying to collect the std(err|out) of a bunch of stuff with a lot of 9s in it from AlexDaniel's history, in the theory that doing that on master and my default-int branch might be good test of that branch | 20:59 | ||
| but i haven't managed to get through all 1225 lines yet without some sort of segv | |||
| jnthn++ had to pass -d and -e options to gdb. here's a gist of the output gist.github.com/MasterDuke17/a6fca...f0d48a8b6c | 21:13 | ||
| brrt | corrupted double-linked list sounds like something glibc would say about malloc | 21:14 | |
| timotimo | yep | ||
| brrt | so probably a heap buffer overflow? | 21:15 | |
| jnthn | Yeah, I'd ASAN of valgrind that thing | ||
| Or at least compile with a lower level of optimization | |||
| timotimo | that is also sometimes the result of free-ing a pointer that didn't come from malloc | 21:16 | |
| jnthn | Because the big clue will be between frames 4 and 5 (where inlining as taken place) | ||
| *has | |||
| timotimo | (still something that happens with HAS int8 @.foo is CArray[int8]) | ||
| MasterDuke | unfortunately i lost the marker of which line it was... | ||
| timotimo | you should be able to get the commandline args from the core | ||
| brrt | ping samcv | 21:17 | |
| MasterDuke | heh. ` Command Line: /home/dan/Source/perl6/install/bin/perl6 9.p6`, not so helpful | 21:19 | |
| timotimo | d'oh :) | ||
| hm | |||
| but perhaps you can get at the source string :D | |||
| if it's a one-liner it's potentially not as easy to find :( | |||
| but maybe try "strings blah.core" | |||
| i.e. the unix strings tool | |||
| hm, but we'd potentially have the string as 32bit values | 21:20 | ||
| so strings wouldn't pick that up | |||
| MasterDuke | `o"; s/(o)/$99999999999999999999999999999999/; .say # wat?I` looks possible | ||
| timotimo | mhm | ||
| MasterDuke | `.lines(-99999999999999999999999999999)` | ||
| oh, there are a ton of them | 21:21 | ||
| i guess because it's a dump of the process that was reading the lines and spawning a new process for each line | 21:22 | ||
| so not very helpful | |||
| timotimo | d'oh | 21:23 | |
| but ... then that one is the one that crashed? | |||
| MasterDuke | could be | ||
| this is its code gist.github.com/MasterDuke17/c1848...31779529b0 | 21:24 | ||
| timotimo | that doesn't look dangerous | 21:25 | |
| MasterDuke | cribbed directly from the docs | 21:26 | |
| Thread 7 "perl6-m" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffedffb700 (LWP 22101)] 0x00007ffff79e0f08 in gc_free (tc=0x55555555b1e0, obj=0x7ffff41d7878) at src/6model/reprs/MVMHash.c:66 66 HASH_ITER_FAST(tc, hash_handle, h->body.hash_head, current, { (gdb) | 21:32 | ||
| timotimo | oh, huh? | 21:33 | |
| it's crashing while trying to free a hash object? | 21:34 | ||
| MasterDuke | gist.github.com/MasterDuke17/949b9...0ccc3de3f4 | ||
| jit was disabled | |||
| should i recompile with --optimize=0 ? | 21:35 | ||
| timotimo | not sure that'd help | ||
| MasterDuke | any other info useful? or should i try to continue? | 21:37 | |
| timotimo | phew. maybe rr recording and going backwards could be interesting | 21:38 | |
|
21:43
brrt left
|
|||
| MasterDuke | now `free(): invalid next size (fast)` | 21:44 | |
| timotimo | aye, with moarvm having a spesh thread (and also async stuff on the async thread) things won't be deterministic | 21:45 | |
| and the same bug can give different corruptions in malloc's data structures | |||
| MasterDuke | gist updated with another backtrace | ||
| it did happen much sooner this time | 21:46 | ||
| timotimo | the backtraces aren't very helpful; it's the same thing with moar's own "invalid id in work pass" and friends errors | ||
| it's really just stumbling over corruption that was created at some point in the past | |||
| MasterDuke | added a perl6 backtrace | 21:47 | |
| timotimo | without asan or valgrind, there's really not much we can learn from those :( | 21:55 | |
| Geth | MoarVM: Kaiepi++ created pull request #1092: Temporarily use -fno-ret-protector when building on OpenBSD |
22:42 | |
| Kaiepi | made an issue related to why that should be temporary #1091 | 22:49 | |
| oh, how do i get the bot to link moarvm issues? | 22:50 | ||
| M#1091 | |||
| synopsebot | M#1091 [open]: github.com/MoarVM/MoarVM/issues/1091 Legojit and ROP vulnerabilities | ||
| Kaiepi | there we go | ||
|
23:21
BeaconAlumna left,
avar left
23:27
BeaconAlumna joined,
avar joined
|
|||