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

Powered by Cro and the Raku® Programming Language.

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

Thank you!