00:08
vendethiel- joined
00:11
btyler joined,
moritz_ joined
01:00
FROGGS_ joined
01:04
avuserow joined
01:23
avuserow joined
02:00
FROGGS__ joined
|
|||
TimToady | cut down version of t/spec/integration/99problems-51-to-60.t with a gdb stacktrace indicating GC issues: gist.github.com/anonymous/5aa8c0d7b4c99d75da35 | 05:19 | |
at first I thought it might be GatherIter depending on sentinel addresses that can move, but changing them to something more constant doesn't help | 05:24 | ||
not that doing address comparisons on [] isn't potentially problem, methinks, but it's not the problem in this case | 05:25 | ||
or do you guys know something about [] that I don't? | 05:26 | ||
(Any.new.WHICH doesn't improve things from the GC perspective, assuming WHICH is not subject to gen2 movement) | 05:27 | ||
also, despite the recursive gathers, it doesn't seem to be related to the batching change that collects up to 1000 takes in eager context; changing that back to 1 still segfaults | 05:31 | ||
it does seem to delay or suppress the failure if we use := instead of = when generating the trees, so eager context does bring the failure earlier somehow | 05:32 | ||
nwc10 | TimToady: that test fails under ASAN (unless SPESH is disabled) | 06:27 | |
(the full sized spectest) | 06:28 | ||
I'm rebuilding master/master/nom with ASAN again to try the cut down version | |||
TimToady | cool, hope it finds something, though these sorts of problems are notoriously heisenbuggy | 06:34 | |
nwc10 | me too, otherwise you've just found a different bug | 06:36 | |
sergot | hi o/ | 06:41 | |
nwc10 | \o | ||
FROGGS | morning #moarvm :o) | 06:45 | |
nwc10 | TimToady: in that gist, if I just run the code in the blocks after "This is from:" ASAN built rakudo doesn't barf. | 06:48 | |
The entire spectest still barfs, with a stacktrace similar to yours | |||
#0 0x7ffb944bac20 in scan_registers src/gc/roots.c:376 | |||
TimToady | well, it's very sensitive to prior activity | ||
that was about as far as I could cut it down here and still get it to misbehave | 06:49 | ||
nwc10 | is trying to read a location 0 bytes after a region allocated by allocate_frame() | ||
FROGGS | I guess that is due to our heat seeking spesh | ||
I once disabled all spesh opts and then enabled them one by one to see what opts make it explode | |||
at that time a combination of two were to blame, so there can be many combinations in this case :/ | 06:50 | ||
nwc10 | FROGGS: I tried to do something similar on PPC and went from SEGV after 8 tests (my actual bug) to instant SEGV. Is there a good way to do that disabling? | ||
TimToady | btw, my snippet still dumped with MVM_DISABLE_JIT | 06:52 | |
FROGGS | nwc10: I just commented out the cases of the switch at src/spesh/optimize.c:1025 | 06:53 | |
dunno if that is a good way or not | |||
nwc10 | I tried to do that. | ||
at least, I thought that I did that | |||
anyway, if I try it again and it fails | |||
then I plan to use git log to work out the reverse order of which things were added to that switch | 06:54 | ||
and comment out one by one | |||
FROGGS | and timotimo++ confirmed that one optimization was buggy, so he commented it out for a while (and fixed it just a week ago IIRC) | ||
nwc10 | Kaboom was on master/master/nom earlier this week | 06:55 | |
and is also in the earlist version I can get to build | |||
so it's probably a different thing | |||
07:02
zakharyas joined
08:06
colomon joined
08:11
colomon joined
08:55
woolfy left
11:47
nebuchad` joined
11:51
bcode joined,
daxim joined
11:54
bcode joined
13:22
lastofthe joined
13:42
FROGGS[mobile] joined
|
|||
lastofthe | Looks like the recent malloc wrappers broke the build on ARM 32 + gcc 4.8.2, the order of the includes might need some shuffling: gist.github.com/anonymous/ce9d200f0f3686c12bff | 13:57 | |
git branch | 14:03 | ||
whups | |||
14:10
moritz_ joined
|
|||
dalek | arVM: 459f317 | jimmy++ | / (2 files): fix the build on ARM 32 + gcc 4.8.2, lastofthe++ |
14:11 | |
arVM: a295bc2 | jimmy++ | 3rdparty/dynasm: fix dynasm |
14:13 | ||
14:21
FROGGS joined,
ingy joined
14:22
_sri joined
|
|||
jnthn | TimToady: About GatherIter, [] is used simply as a sentinel object, and it's quite clear that since [] is mutable then instances will be unique. Could be anything else wiht similar properties. I just stuck with what sorear++ picked, seeing no reason not to. :) | 14:23 | |
Also, it was used as an object pointer comparison | 14:30 | ||
And those all move together while the world is stopped | 14:31 | ||
14:33
17SAA04J2 joined
|
|||
moritz stops the world | 14:33 | ||
jnthn gets off | 14:35 | ||
diakopter | *cry* | 15:00 | |
tadzik | quick, come back while it's still | 15:02 | |
15:15
lizmat joined
15:21
woolfy joined
|
|||
TimToady will just use Mu.new then, since it's a minimal unique object, and requires no attribute storage | 15:34 | ||
and is sufficient for =:= purposes | 15:35 | ||
jnthn | +1 | 15:36 | |
TimToady | [] actually has a bunch of stuff inside that is just wasted allocation | ||
jnthn | Well, it's a singleton ever so we're talking O(bytes), but yes :) | ||
TimToady | not a major thing, of course, we don't do that many gathers | ||
there was actually a huge debate in the early days of Ada whether an empty record was good for anything :) | 15:37 | ||
jnthn grumbles about his latest startup time reduction making startup longer... | 15:38 | ||
TimToady discovered it was good as a peg to hang procedural code in the middle of your declaration elaboration sequence | |||
jnthn | oh, wtf... | ||
15:42
itz_ joined
|
|||
avuserow | timotimo: sad news. moar segfaulted with profile-compile after some large number of hours :( | 16:38 | |
it claims it dumped a core file but I don't actually see one | 16:39 | ||
oh it may not have had enough disk space to make an appropriately sized core file. | 16:40 | ||
timotimo | ah damn :( | 16:52 | |
but thanks for doing stuff | 16:57 | ||
avuserow | I added some disk space and reran it without the --optimize flag, so I'll see if that does anything | 16:59 | |
timotimo | that'll cut a bunch of calls everywhere, aye | 17:00 | |
actually, without --optimize, --optimize=2 is assumed | |||
avuserow | oh | 17:01 | |
timotimo | you could --optimize=off | ||
avuserow | so I should do --optimize=0? | ||
ok | |||
timotimo | there is off and 0, i believe | ||
if you do "off" the optimizer will be skipped entirely | |||
with 0, i think it only does analysis | |||
avuserow | oh I should also do --gen-moar=master and --gen-nqp=master too probably? | ||
timotimo | i would do that, aye | ||
avuserow | at this point, I'm mostly curious if it's possible to complete a run and get useful data. I can tweak and re-run after that. | 17:03 | |
timotimo | in theory, we could make a specialized version of the compiler that only profiles the stage "parse" and then only profiles the stage "optimize" and so on | 17:04 | |
avuserow | is there any way to get the peak memory usage of a process? | ||
17:05
zakharyas joined
|
|||
timotimo | sure, "time" gives you that in the "maxresidentk" slot | 17:05 | |
avuserow | oh, cool. (and that appears to be /usr/bin/time, and not the shell builtin.) | 17:07 | |
timotimo | ah, right, depending on the shell you may get one that's not as nice | 17:11 | |
the system time also has -v which gives you the values of different performance counters | 17:12 | ||
like how many branch predictions were missed and such | |||
avuserow | yeah this is just default unconfigured bash on ubuntu server 14.04 | 17:14 | |
timotimo | i'm personally enjoying FISh a whole lot | ||
avuserow | I had an ISO for it laying around and it installs quickly. no other reason for using it | ||
anyway, if the process crashed last night due to a lack of memory, it must've requested >80GB or about, since I also enabled 40GB of swap | 17:16 | ||
timotimo | FISh isn't a distro, it's a shell :) | ||
avuserow | right | ||
timotimo | though in the #fish channel i met a person who wanted to build a linux distro around fish | ||
avuserow | I haven't looked at fish in many years, not since I learned the basics about shells. I mostly use zsh with a nice variety of configurations | 17:17 | |
timotimo | ah | 17:41 | |
i've been on zsh with lots of conf before switching to fish | |||
recently i got the one thing back that i was lacking: alt-q | 17:42 | ||
lastofthe | clang throws a bunch of warnings about converting between integer types with different sign. Is "assigning to 'char *' from 'MVMuint8 *'" safe? | 17:47 | |
dalek | arVM: efff2fd | (Timo Paulssen)++ | src/moar.h: pre-declare MVM_jit_support in moar.h; fixes #135 |
17:48 | |
arVM/dynamic_gen2_tuning: 23a5c6e | TimToady++ | src/core/args.c: Better style on arg count errors Inverted got/expected order, also s/parameters/arguments/. |
18:05 | ||
TimToady | oops, wrong branch | ||
did we ever merge that branch? | 18:07 | ||
FROGGS | would be the safest to cherry-pick that commit to master | 18:09 | |
TimToady has to learn to cherry-pick, I guess | |||
FROGGS | git checkout master; git cherry-pick 23a5c6e | 18:11 | |
[Coke] | note that cherry picking means merging that branch later might be rough. | ||
FROGGS | [Coke]: are you sure? | ||
TimToady | I would think that would make it easier, since it has the provenance | 18:12 | |
FROGGS | I always had the impression that git knows that this commit is already there | ||
TimToady | with just applying the patch, it would have to do diffs and stuff | ||
FROGGS | for example I cherry-picked something from the labels branch, and then merged it without problems | ||
[Coke] | it doesn't know that the cherry pick is the old commit. | 18:13 | |
ok. some FUD to ignore, then. | 18:14 | ||
dalek | arVM: 288410e | TimToady++ | src/core/args.c: Better style on arg count errors Inverted got/expected order, also s/parameters/arguments/. |
||
nwc10 | did anyone do anything that was supposed to fix the ASAN failures on t/spec/integration/99problems-51-to-60.t | 18:28 | |
and the other 2 tests? | |||
TimToady | not that I know of | 18:30 | |
otoh, it seems to pass now | 18:31 | ||
otgh, I was testing against dynamic_gen2_tuning, not master | |||
and that's likely to have changed the GC characteristics | 18:32 | ||
so might still be a flapper | |||
dalek | arVM/cglobal: d52b745 | (Tobias Leich)++ | / (8 files): expose C globals like native subs |
18:34 | |
Heuristic branch merge: pushed 21 commits to MoarVM/cglobal by FROGGS | 18:35 | ||
TimToady | still fails under the harness | 18:38 | |
19:07
Ven joined
19:10
zakharyas joined
|
|||
nwc10 | so my SEGV on PPC goes away when I comment out "case MVM_OP_getattrs_n:" in optimize_bb | 19:17 | |
investigations will continue tomorrow | |||
but this is progress | |||
FROGGS | indeed | 19:23 | |
lastofthe | nwc10: sweet. That could help my ARM twisting. | 19:34 | |
19:35
brrt joined
|
|||
brrt | \o | 19:35 | |
JimmyZ: what changed in the dynasm? | 19:38 | ||
FROGGS | brrt: it is just about your latest commit here I think: github.com/MoarVM/dynasm/commits/master | 19:46 | |
brrt | oh.. i thought i had done that yet :-) | ||
but apparantly not | |||
19:51
itz joined
|
|||
lastofthe | 'though clang 3.4 will build (warningly) moar on ARMv7, unaligned reads get crashy. Here's a patch: gist.github.com/anonymous/7b1a7e81cbca6123d224 | 20:47 | |
20:47
Ven joined
21:02
brrt left
21:41
itz_ joined
21:46
itz joined
21:56
itz_ joined
22:49
lastofthe joined
|
|||
lastofthe | clang on arm troubles filed with patch as #137. | 22:57 | |
avuserow | A friend wants to know if there is a SuchVM since there is a MoarVM. | 23:17 | |
avuserow .oO( SuchVM. Very Execute. Wow. ) | |||
lastofthe wonders where Configure.pl might put the compiler's -W flags... | 23:31 |