Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-11-14

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:37 jimmy_ joined #moarvm
03:38 jimmy_ joined #moarvm
04:28 zakharyas joined #moarvm
06:11 kjs_ joined #moarvm
07:16 FROGGS joined #moarvm
07:37 woolfy joined #moarvm
08:17 woolfy left #moarvm
08:20 zakharyas joined #moarvm
11:04 ggoebel111111119 joined #moarvm
12:21 JimmyZ joined #moarvm
13:27 brrt joined #moarvm
13:27 brrt \o
13:29 jnthn o/ brrt
13:30 brrt \o jnthn
13:30 brrt back from holiday?
13:30 jnthn Yes
13:30 jnthn And loaded up with $dayjob...
13:30 jnthn :S
13:30 brrt nice :-) how was it?
13:30 brrt ah that happens
13:30 brrt :-)
13:30 jnthn Vacation was nice :)
13:30 jnthn .nz is very pretty
13:31 jnthn And with good pubs :)
13:31 brrt you went to new zealand?
13:31 jnthn Yeah
13:31 brrt awesome
13:31 jnthn It's....a long way. :)
13:31 jnthn But worth it.
13:31 brrt i'd love to go once
13:31 jnthn Stopped in KL and Singapore as city breaks on the way there/back to make the trip more tolerable. :)
13:31 brrt i see :-)
13:32 jnthn They were also pretty cool. Especially Singapore...it has great food.
13:32 brrt kuala lumpur and singapore are not that remote from each other, are they
13:32 brrt or at least from the european perspective
13:32 jnthn Pretty close, yeah
13:33 brrt i'm working on something that i want to surprise #perl6 with... but i wanted to ask you about something
13:33 jnthn :)
13:33 brrt basically, rakudo currently hard-codes all the flags used to compile-and-link something with moarvm
13:34 brrt in fact, those flags are all determined during compilation of moarvm
13:34 brrt in fact, during Configure.pl's run
13:34 jnthn Right
13:35 brrt so we could embed these flags in moarvm - as a compile-time-constant - and have moarvm carry them over
13:35 brrt that would make it easer for third parties to #include <moar.h> and link libmoar.so :-)
13:35 brrt or libmoar.dll, whichever you fancy
13:36 jnthn Isn't that already done?
13:36 jnthn nqp --show-config
13:36 jnthn That uses the info...
13:37 brrt hmm let me check
13:38 brrt hmm
13:38 brrt how does that even work
13:38 jnthn MAGIC AND HIGH PONIES
13:38 brrt clearly :-)
13:38 jnthn I think there's a MoarVM op that obtains it
13:38 brrt ok, that is a basis to do that
13:38 jnthn And we compile in the data
13:39 jnthn Likely it's mapped to some nqp:: op on Moar too
13:39 brrt :-)
13:39 brrt ok, we can use that... i can use that
13:42 jnthn ;)
13:42 * jnthn looks forward to seeing the secret project. ))
13:45 * brrt hopes not to have given a too great impression yet
13:45 brrt :-)
13:50 zakharyas joined #moarvm
14:28 lizmat joined #moarvm
14:39 woolfy joined #moarvm
14:45 JimmyZ joined #moarvm
14:56 synopsebot joined #moarvm
15:33 kjs_ joined #moarvm
15:35 Util joined #moarvm
16:02 timotimo i think i know what brrt is up to %)
16:07 jnthn Destroying the universe? /o\
16:10 timotimo if so, then only as an accidental byproduct
16:22 japhb Now, now, no destroying the universe before we've all had a good breakfast.  Because if I'm going to pop out of existence, I at least want to be well fed.
16:22 japhb .oO( The Surreal Life )
16:51 [Coke] still lots of jit failures vs. non-jit
16:51 timotimo jnthn: do you think we should do analysis based on "this variable has been checked with that operation in the dominance parent and thus we can assume this here fact holds true"?
16:52 zakharyas joined #moarvm
16:52 [Coke] https://github.com/coke/perl6-roast-data/blob/master/log/rakudo.moar-jit_summary.out#L2812 vs. https://github.com/coke/perl6-roast-data/blob/master/log/rakudo.moar_summary.out#L2835
16:52 timotimo er ... do you think we should do it soon
16:52 [Coke] non jit seems to be memory errors, jit seems to be segfaults.
16:53 timotimo [Coke]: can you reproduce the failure in delete-adverb with any of MVM_SPESH_DISABLE and MVM_JIT_DISABLE set?
16:53 kjs_ joined #moarvm
16:54 [Coke] timotimo: assuming that runs the same code as a non-jit moar, no. :)
16:54 [Coke] one sec.
16:55 [Coke] I can't duplicate the error outside of my test run, even.
16:56 timotimo oh, of course m)
16:56 [Coke] but it happens pretty regularly inside the test runs.
16:56 timotimo that was a big derp
16:58 [Coke] here:
16:58 [Coke] echo "S32-hash/delete-adverb.t" > a ; PERL6LIB=lib perl t/spec/test_summary rakudo.moar a
16:59 [Coke] that uses the test_summary harness to run that one file. That reliably gives the malloc error here on the mac.
16:59 [Coke] still does with MVM_SPESH_DISABLE and MVM_JIT_DISABLE both set to 1
17:00 timotimo wow.
17:00 timotimo let me try ...
17:01 [Coke] er, one sec.
17:01 timotimo yeah, on my linux box i can't reproduce that :(
17:01 [Coke] ok. with MVM_SPESH_DISABLE=1 OR MVM_JIT_DISABLE=1, it doesn't give the memory error.
17:02 [Coke] (I had added them before the -echo-, not the "perl t/spec...")
17:02 timotimo ah
17:02 jnthn What about just MVM_JIT_DISABLE?
17:03 [Coke] timotimo: AHAHAHAHAHAHAAH
17:03 timotimo mac should have ulimit, too, right? ulimit -c unlimited and inspect the core dump with gdb?
17:03 timotimo what's wrong now? %)
17:03 timotimo wrong .... or very right perhaps?
17:04 [Coke] I just did a perlbrew invocation. and the error went away. and now I cannot make it come back in this bash.
17:04 timotimo so environment variable related trouble?
17:05 timotimo LIBUV_CRASH_SOMETIMES=1
17:05 jnthn Or different env var count leads to slightly different memory layout leading to hiding/revealing the issue...
17:05 [Coke] jnthn: that woudl be very persnickety. confirmed. fresh shell, dies repeatedly. if I do "perlbrew off", it works.
17:06 jnthn [Coke]: What about just with MVM_JIT_DISABLE, and not MVM_SPESH_DISABLE?
17:06 jnthn [Coke]: Could also try just with MVM_SPESH_INLINE_DISABLE=1 and MVM_SPESH_OSR_DISABLE=1
17:06 jnthn (and MVM_SPESH_DISABLE unset)
17:08 [Coke] jnthn: just MVM_JIT_DISABLE=1; no errors.
17:09 [Coke] just MVM_SPESH_INLINE_DISABLE=1; no errors
17:09 [Coke] just MVM_SPESH_OSR_DISABLE=1; no errors
17:09 jnthn grmbl
17:10 jnthn That doesn't, sadly, narrow it down as much as I'd hoped...
17:10 timotimo we should write a little shell script that sets different env vars to different length values
17:10 [Coke] timotimo: this particular failure is a memory issue, not a core dump.
17:10 timotimo memory issue, as in?
17:10 [Coke] let me see if I can run gdb instead of moar here.
17:10 jnthn Though we may just be hiding the issue by disabling features rather than actually turning off features that caues the issue...
17:11 [Coke] S32-hash/delete-adverb.t..moar(56870,0x7fff7987b310) malloc: *** error for object 0x7fedef6f2b20: pointer being freed was not allocated
17:11 timotimo ah
17:11 [Coke] I feel like I should rename this box "canary". :)
17:12 jnthn .oO( And I can 'cus it's mine ;) )
17:15 [Coke] DOH.
17:15 [Coke] (jnthn's pun)
17:15 [Coke] ok, I think I figured out how to make this launch lldb (os x, so no gdb)...
17:16 [Coke] ... or not. seems to be hanging now.
17:17 [Coke] googling to find how to diagnose this, found this quote:
17:17 [Coke] We found the issue. We were using memset on the z variable which worked fine in 32-bit but it was clearing the wrong size of its memory block and corrupting the 64-bit block. –  GW.Rodriguez Jan 14 '13 at 20:26
17:18 [Coke] ooh, https://developer.apple.com/library/mac/documentation/performance/Conceptual/ManagingMemory/Articles/MallocDebug.html (more env vars)
17:20 [Coke] of course, if I enable, say, MallocStackLoggingNoCompact ... the error goes away. :P
17:26 japhb [Coke]++ # Dogged persistence
17:28 [Coke] ... and with that, I'm out. :)
17:28 [Coke] (seriously, time for walkies and food)
17:34 [Coke] ah, one more important find. even BARFTACOS=1 makes the error go away.
17:43 [Coke] Does moar run multiple threads by default?
17:45 jnthn No
17:48 [Coke] changing "plan 131" to "plan *" in the test file makes the error go away. :(
17:49 jnthn [Coke]: No look running it under the debugger and getting a stack trace?
17:50 [Coke] it's so finicky to get the error to occur in the first place. :| if I change ./perl6 to start with "exec lldb --", it seems to hang.
17:51 [Coke] woohoo.
17:52 [Coke] jnthn: https://gist.github.com/coke/a6f7f41f05ee4dd4a64f
17:53 jnthn [Coke]: What if you "bt" there?
17:53 [Coke] refresh - there's a bt.txt file there!
17:54 [Coke] I set a breakpoint at the method it said to, reran, got the error, then did the bt.
17:54 jnthn eek
17:55 jnthn Unfortunately, there's multiple gc_free methods, and this build hasn't line numbers
17:55 jnthn But I only need to consider gc_free methods that call MVM_free...
18:02 [Coke] aside from line numbers, anything else I can provide?
18:02 [Coke] I might be able to do a debug build, but I suspect that will also hide the bug. :)
18:02 jnthn [Coke]: The file/line number is enough
18:02 jnthn [Coke]: Though...
18:02 FROGGS joined #moarvm
18:03 jnthn [Coke]: Hm, no, I think there's nothing more that can be done.
18:03 jnthn [Coke]: Was going to say if you can walk up the frames, and look at an arg - but there's not enough info around to do that, I think.
18:04 jnthn There's only so many gc_free methods that call MVM_free
18:07 jnthn Knowing which one it is would help a good bit, but also this means it's likely decreasing nursery size will make the bug show up more too, perhaps
18:07 [Coke] doing a rebuild with debug.
18:08 jnthn [Coke]++
18:30 [Coke] https://gist.github.com/coke/a6f7f41f05ee4dd4a64f updated.
18:32 [Coke] it's MVMString's gc_free.
18:48 kjs_ joined #moarvm
19:07 [Coke] jnthn: opened https://github.com/MoarVM/MoarVM/issues/154
19:08 timotimo but how does a b0rked pointer get in there?
19:08 timotimo can you check out what the MVMString's data looks like?
19:09 timotimo usually a 32bit-per-grapheme storage, i believe
19:11 [Coke] (lldb) p *str
19:11 [Coke] error: Couldn't materialize: couldn't get the value of variable str: no location, value may have been optimized out
19:13 timotimo ah
19:13 timotimo i bet if you build with more debug, less optimization the problem goes away, too
19:17 [Coke] I can't get output on anything. :(
19:18 [Coke] might be PEBKAC with lldb.
19:20 kjs_ joined #moarvm
19:20 timotimo hum :\
19:21 timotimo may want to try if the symbol is available in one of the outer frames?
19:23 [Coke] --debug might not be sufficient for OSX debug stuff.
19:24 [Coke] I need whatever xcode does when you pick Debug mode, I guess.
19:26 timotimo probably --optimize=0?
19:30 [Coke] trying.
19:43 [Coke] nope, no help
19:44 timotimo >_<
20:18 colomon joined #moarvm
20:53 oetiker joined #moarvm
20:56 Ven joined #moarvm
21:06 kjs_ joined #moarvm
23:14 timotimo what does takedispatcher being null or not null mean? is that about nextsame and friends?
23:47 timotimo https://gist.github.com/timo/de0ef5d3f5e159117d2b
23:47 timotimo argh argh
23:49 [Coke] urk urk
23:50 JimmyZ joined #moarvm
23:53 JimmyZ hmm, It'd be nice if we will have static optimization when writing to *.movarvm, like `set ` op removal
23:55 timotimo not terribly easy
23:55 timotimo most of these sets are hllize or deconts

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary