00:36 agentzh joined
samcv got this MoarVM panic: Internal error: invalid thread ID -1525282512 in GC work pass 01:05
anybody gotten this error before?
i know i've seen the error before, but forget if previous times had a negative thread id
01:17 zakharyas joined
lizmat samcv: the negative thread ID indicates memory corruption to me, so it probably went off the rails quite before that 03:50
samcv kk 04:16
yeah that's odd i haven't seen that for a while now. and haven't seen it since
(with the same file)
05:16 pyrimidine joined 07:36 agentzh joined 08:09 Ven joined
dogbert11 samcv: so when did you get this MoarVM panic? 08:33
samcv running my UCD-gen.p6
was weird 08:34
dogbert11 is that program in the Rakudo or MoarVM repo? 08:35
samcv it's here github.com/samcv/UCD/blob/master/UCD-gen.p6
it's kind of a big program tho
and i don't use any threading
first time i got it running the script out of the many times i've run it 08:36
dogbert11 interesting
moritz samcv: btw, what's the state of your grant?
samcv not reproducible
moritz, will be going for the March one
so waiting for March review
moritz samcv: ok, thanks
samcv proposal is mostly the same gist.github.com/samcv/77b2ef7c972c...90de4fda39 just made a few corrections/added a few more detail to a couple things 08:41
dogbert11 samcv: how am I supposed to use this program, just starting it doesn't seem to do much 08:52
samcv see the readme
github.com/samcv/UCD#how-do-i-build-this 08:53
dogbert11 that's cheating :)
samcv i would recommend doing perl6 UCD-gen.p6 --no-names
otherwise it'll take a really long time. and the crash happened when i ran with --no-names
and has .travis.yml too if you don't believe my readme :P 08:55
dogbert11 running it now with --no-names 08:58
09:01 Ven joined 09:06 geekosaur joined
dogbert11 of course it works when you want it to crash 09:24
samcv well it only crashed that one time 09:28
09:42 Ven joined 09:44 zakharyas joined
dogbert11 tada: Writing source/binary-properties.Dump.p6ā€¦ 09:46
MoarVM panic: Internal error: invalid thread ID 342051784 in GC work pass
but now I have to make it happen again in gdb ... 09:47
jnthn Sticking GC debug mode on usually makes those show up at the point of worklist addition
dogbert11 GC debug mode was on :) 09:50
jnthn: any theories or do you want a backtrace to look at?
jnthn It could be anything :) 09:51
So no, we'll need backtraces etc.
dogbert11 well, hopefully it will be easier to get good data than the harness6 fiasco :(
ASAN does not want to cooperate there 09:52
samcv dogbert11, interesting that it crashes there 09:53
i believe it calls .perl on %binary-properties and spurts to a file
err no maybe it calls Dump 09:54
yeah it calls Dump
from the module or whatever
dogbert11 interesting, btw I had set the nursery to 128k as well 09:55
and I had forgot to compile with --debug grrrr 10:00
10:02 brrt joined
dogbert11 jtnhn, samcv: gist.github.com/dogbert17/45ba25e3...008018ba06 10:13
s/jtnhn/jnthn/ 10:14
samcv i gotta go to bed. night all o/ 10:18
dogbert11 night
jnthn dogbert11: Hm, is that with MVM_GC_DEBUG turned on? 10:20
dogbert11 yes, set to 2, optimization is also on 10:22
dogbert11 double checks ...
dogbert11 and MVM_GC_DEBUG 2 10:23
will it help if I build MoarVM with --no-optimize? 10:25
jnthn Doubt it, the debug checks should trip sooner 10:27
Thing is, MVM_GC_DEBUG=1 should cause it to blow up when the item is put into the worklist
brrt good *, #moarvm, also, sleep well samcv 10:28
jnthn hi brrt
dogbert11 is there a check missing somewhere? 10:29
jnthn I can't think where it would be missing
brrt hi jnthn
jnthn I think there's only one worklist addition code path
dogbert11 so it's a mystery then :)
10:31 agentzh joined
dogbert11 on the positive side it seems easy to reproduce 10:34
brrt easily reproduced bugs don't stay mysteries for long, usually 10:36
dogbert11 hopefully jnthn figures it out 10:37
dogbert11 sneaks away for lunch 10:55
timotimo the "syscall param points to uninitialized bytes" is - i think - about us honoring alignment and not explicitly setting some bytes, though you'll notice we've allocated the blob with calloc, which means we do get zeroed bytes 12:34
unless we realloc or something?
12:43 pyrimidine joined
dogbert11 jnthn, timotimo: let me know if you want me to do another run or test something else wrt this problem 13:06
timotimo i'm running it through valgrind at the moment :) 13:09
an ASAN run might be interesting
brrt ASAN++ 13:10
dogbert11 I was just about to do an ASA run, rebuilding atm 13:13
timotimo it's at the "packed-enums: ..." stage right now 13:25
13:27 nebuchad` joined 13:30 ilmari_ joined, BinGOs_ joined 13:32 dalek joined
nwc10 dalek: lunch! 13:42
13:50 BinGOs joined
timotimo making point_index 14:10
dogbert11 no invalid reads/writes? 14:12
timotimo none yet
Took 1084.3415487 seconds to compute point_index ranges 14:28
14:33 agentzh joined, japhb joined
timotimo Writing source/PropertyNameAliases_to.Dump.p6ā€¦ 14:43
14:45 brrt1 joined
timotimo i may have to run it a second time 14:48
but it takes like 1.75 hours %) 14:49
dogbert11 why do you have to run again? 14:50
14:51 colomon joined
timotimo because it didn't error out at all 14:55
dogbert11 some bugs are tricky and refuses to show their ugly faces when you want them to :) 15:03
timotimo right 15:14
dogbert11 although I'm not entirely sure about what was wrong with the gdb backtrace 15:17
timotimo it didn't help us figure out where the problem was 15:18
something was likely corrupting the header of an object at some point, then the program continued merrily, until GC started, and that's where it exploded 15:19
dogbert11 I see, and we're hoping that valgrind and/or ASAN will provide the location of the real problem 15:20
timotimo right 15:21
valgrind and asan usually introduce "redzones" around allocations
can you try what values of --less will still give you a crash?
10000? 20000? 30000? 15:22
dogbert11 I should point out that I had set the nursery size to (32768 * 4) when I used gdb
timotimo ah, i might have to reduce the nursery size a bunch, too
where do i do that?
dogbert11 collect.c
sry, collect.h of course 15:23
timotimo got it
dogbert11 what does --less do? never used it before 15:25
timotimo it pretends there's only the first N codepoints in unicode
reduces the workload a bunch 15:26
dogbert11 cool, that might come in handy
timotimo there's a bit more than a million codepoints
so you can divide the workload by 10 by giving 100000 as the --less argument 15:27
since it crashes at the very end, it'd be nice if it didn't take quite as long :)
15:35 pyrimidine joined 15:41 pyrimidine joined 15:59 pyrimidine joined
dogbert11 with 128k nursery and --less=15000 I can recreate the crash 16:02
16:17 brrt joined
timotimo got it 16:51
gist.github.com/timo/e81ea20afb923...3ba85037bc
that's ... weird 16:52
17:06 pyrimidine joined 17:16 dogbert17 joined
dogbert17 timotimo++ 17:16
timotimo it could be we're messing up strands somehow somewhere? 17:19
dogbert17 does the problem start in MVM_string_repeat then? 17:23
timotimo it's not out of the question 17:24
jnthn It's at least interesting that all the stack traces seem to start in there
timotimo i've turned on strand debugging, which ought to read through every single string's strands all the time
i expect the stack "ends"/"starts" there because of jitting? 17:25
AFK while the thing runs again
maybe for a good while longer this time
jnthn In MVM_string_repeat 17:26
result->body.storage.strands = allocate_strands(tc, 1);
A little further down
MVMROOT(tc, result, {
a = collapse_strands(tc, a);
});
If allocate_strands returns non-zeroed memory then collapse_strands triggers GC, then we have an MVMString with junk in it 17:27
timotimo ooooh
jnthn Should probably set result->body.num_strands = 1; at the end
timotimo huh, at the end? 17:29
we already do that immediately after allocate_strands, though?
jnthn Yes, if you do it at the end then it will be zero when we hit GC 17:31
And so we won't look at the strand memory
timotimo ah, move it to the end, not add it
right.
jnthn Yes :)
But we should maybe audit other cases of allocate_strands to make sure they aren't equally vulnerable
dogbert17 insidious bug 17:32
timotimo sure. after my AFK i might do that, or you can do it while i'm away
jnthn is a tad busy sorting out a $other-job thingy at the moment :) 17:33
17:34 japhb joined
dogbert17 should the line (result->body.num_strands = 1) be moved to before/after this line? 'result->body.storage.strands[0].repetitions = count - 1;' ? 17:41
17:42 ggoebel joined 18:00 pyrimidine joined
samcv morning all 18:03
dogbert17 morning samcv 18:04
18:23 agentzh joined
samcv glad i found a bug for you guys :) 18:48
18:54 ggoebel joined
timotimo yup, good work 19:23
samcv I wish this code was faster :( github.com/samcv/UCD/blob/master/U...#L808-L857 19:24
takes 70 seconds on my machine. i guess i should be happy. it used to take like 19:25
10x that at least
essentially what it does it go over every point, and creates a bitfield row for it that is comma delimited, then checks if there is an existing key in a hash
if there is, then it sets the point's index to that bitfield row, if it doesn't exist it adds a new bitfield row 19:26
thereby deduplicating all the points properties
timotimo hashes with actual Int keys got faster today 19:27
samcv well the sorting isn't that slow actually 19:28
it's all the other operations that's slow
*.Int is not too slow, but +* is like 6x slower than .Int
timotimo can you reasonably pull that section out into a separate sub? 19:29
then we can get a spesh output of the bytecode it actually runs post-opmitization
we could run it under callgrind with "instrument from the beginning" turned off and before the section we shell out to valgrind-control to turn instrumentation on and after the section we turn it off again 19:31
samcv it is its own sub?
timotimo the part you've marked is in the middle of a bigger sub
samcv oh 19:32
oh that, not where the crash is
timotimo it has one for loop before it :P
yeah
samcv ok i can do that
i am glad my bitfield packing seems to work flawlessly. always gives the same result, and it's always packed it perfectly 19:38
timotimo fantabular! 19:39
samcv eventually may make the source file smaller by packing them into larger integers, but that is easy enough to do, and should be done last, because it's way easier to debug by looking at the actual bitfield rows, when what is there actually directly coorasponds with a properties actual value 19:40
timotimo mhm
samcv and i have tests for almost all of the modules :)
timotimo i'm not sure i entirely understood your last paste, the brainstorming piece of code 19:41
but i did have this thought:
encode the start of the range, and the length rather than the end
because i'd imagine all lengths fit into less bits than every starting position does
oh, and also
you could pack the whole thing into two parts, the first of which uses less bits for the starting field also
that'll still allow for binary search, which having only differences between starting points for example wouldn't do 19:42
samcv yeah 19:53
though i have to benchmark it and see, because it could be that huge if else chain is faster
due to compilier optimization 19:54
timotimo don't forget that you can build the if/else chain so that it actually implements binary search
samcv yes true
timotimo en.wikipedia.org/wiki/Sorting_network - cf this not very good wikipedia article 19:55
though of course it isn't the same thing
samcv yeha 19:58
the book i got is helping me brainstorm, even thoug hmost of it concerns datasets that may need to be reordered, but it goes over a lot of different things 20:00
good for inspiration 20:01
turns out the one i got on amazon is the Eastern Economy Edition, and is from India originally lol. guess they sell it for $5 there
though looks like it was written in somebody born in the us
but this one had the fastest amazon shipping, maybe because this is a reprint of the 1996 version or something 20:02
dunno
guessing the original was hardback and much larger, so not bad that it's paperback and fairly compact 20:03
oh crap looks like it's 166 new on amazon. yikes heh 20:04
this is the book www.amazon.com/Data-Structures-Usi...0130369977
timotimo i just noticed i still have that gist open 20:05
20:58 pyrimidine joined
samcv updated that datastructure gist. was a bug in the actual c code. well looks like it now performs identically at least up to cp 1114128 lol 21:13
to the giant if else chain 21:14
gotta time it though
well the if else chain seems to be pretty fast 21:18
i can't even time this going from cp 0 to 128336 100 times
jnthn What if you visit them in a random or non-sequential order? 21:19
samcv adds some zeros
not sure yet
jnthn The if branch one will me sensitive to branch predictor hits
samcv but both of them are linear, the ifelse chain and the other data structure
jnthn And I'd suspect going sequential is the best case for that.
samcv yeah
./build/bitfield 0.00s user 0.00s system 0% cpu 0.002 total
jnthn Unless it's magically compiling it into jump tables :)
samcv that's 10,000 loops
it could be 21:20
if (cp >= 14) { return_val -= 14;
if (cp <= 27) return 0;
if (cp >= 71) { return_val -= 20;
and return_val gets subtracted every level
so i thought it'd be slower. but the compilier may work magic
since that's the only thing the function does
maybe i can try reverse order
ugh i added maok it's def working. i added a print 21:22
and now my terminal is frozen. and that's the outer loop i had the print in
so it seems quite fast
samcv keeps adding more zeros
ok yeah it still has no perceptible time to 21:23
loop 10000000000 times through cp's 0 through 128,336
same thing for cp's 0 through 983040 21:24
like can't even time it period 21:25
for either of them actually :P 21:26
argh even looping 17446744073709551616u times 21:29
i can't time this
i guess that's a good thing :)
i already did close to the largest uint64 21:30
21:30 ggoebel joined
samcv same doing it in reverse cp order 21:30
why do the perf results look identical hmm 21:38
maybe it's just so fast i can't see any difference or whatever. but i would have thought i'd see a difference between the if/else chain and the table of values in a while loop 21:40
timotimo is the compiler perhaps compile-time-evaluating something in there? :) 21:41
samcv i dunno
gist.github.com/f5afa9f03fd119dbe7...2cf8a4cda3 this is bitfield.c 21:42
here's bitfield.h gist.github.com/80500585c276c5486b...e792ebf9a9
but just dl and scroll to int main
at the very very bottom 21:43
get_bitfield_offset(i); // old if else chain get_offset_new(i) ; // new with the table and while loop
fyi
timotimo mhm 21:44
which version of the thing should i run? 21:47
0000000000400400 <main>: 21:49
400400: 48 83 ec 08 sub $0x8,%rsp
400404: 48 be 00 00 9c 58 4c movabs $0xf21f494c589c0000,%rsi
40040b: 49 1f f2
40040e: bf 50 8a 40 00 mov $0x408a50,%edi
400413: 31 c0 xor %eax,%eax
400415: e8 d6 ff ff ff callq 4003f0 <printf@plt>
this is very fast assembly
jnthn m: say "If it does 17446744073709551616 iterations in a second it's doing {17446744073709551616 / 3_000_000_000} per clock cycle on a 3GHz CPU"
camelia rakudo-moar aac9ef: OUTPUTĀ«If it does 17446744073709551616 iterations in a second it's doing 5815581357.90318387 per clock cycle on a 3GHz CPUā¤Ā»
jnthn That's quite some superscalar :P
timotimo yeah, pretty good 21:50
jnthn I think the compiler is being smart enough to optimize the whole operation away :P
timotimo yup
definitely is
1486618624 - that's what it prints out
m: say 0x408a50
camelia rakudo-moar aac9ef: OUTPUTĀ«4229712ā¤Ā»
timotimo hm, not that one
oh, because it xors the other value into it 21:51
m: say 0x408a50 +^ 0xf21f494c589c0000
camelia rakudo-moar aac9ef: OUTPUTĀ«17446744073713781328ā¤Ā»
samcv which operation away?
the if else chain?
timotimo all of it.
samcv wat
timotimo the whole call to the function is gone
and the loop is also gone
samcv wow
jnthn Compilers these days... :P
samcv wtf lol
would be interesting to compare what it does different for the two
but the data structure is still there? 21:52
even thoug the function that calls it is basically compiled away?
timotimo yup, it's still there
samcv so it's not calling it like milions of times?
timotimo the function that uses it is available for dynamic loading
nope, it's not calling it even once
samcv damn 21:53
because its value isn't used?
damn you compilier!
timotimo no, because the input is always the same
make it depend on argv[0] or so
samcv the value of i changes though?
timotimo that'll prevent this
no, the value of i always starts at 0 and always ends at the same value
and it sums up stuff, that sum is always the same
and it just prints that value at the end 21:54
samcv lol.
timotimo oh
it really isn't even using the return value at all
i misread your c code
but yeah, it found that the get_bitfield_offset function has no side effects
samcv how do i actually get it to bench it properly
timotimo take the result from the function and do any kind of arithmetic on it 21:55
that might be enough
also, the result probably has to be printed out
or it'll say "well, this isn't ever used anywhere, and it doesn't escae the stack, so off with its head!"
samcv heh
ok yeah i added a printf but didn't use its value 21:56
printf("", get_bitfield_offset(i))
timotimo yeah, that won't help
gcc knows about formatting strings
samcv well it doesn't complete
geekosaur gcc looks inside.. that
yes, compilers are smart 21:57
timotimo not ours though
geekosaur there's a moderately infamous quote in #haskell where someone tried to demonstrate how "bad" a particular operation would be... and ghc optimized it to a constant
timotimo :) 21:58
samcv lol
timotimo yeah, gcc will do that
geekosaur or something fairly trivial and highly optimized
timotimo if you have a modulus by a constant number, it'll generate the weirdest-looking code
it's really quite impressive to see
samcv ok i got it printing it out and takes 1 second to do from cp 983040 to 0 21:59
now to actually compare things :)
i expect the one with the table to be slower though 22:00
since it starts at 0 and goes to the end
timotimo going through the cp list in a series like that ... it'll make the branch predictor jump with joy
22:00 pyrimidine joined
samcv 1068.487411 s for the if else chain and 1854.454758 for the table that does linear 22:01
that's sorta what i expected
curious how it would compare if it did binary search
oh waiot. let me take that last one again
oh the table one took 820ms 22:02
so it's actually faster even with linear search
timotimo interesting
samcv did not expect that
and the data they output is identical. so \o/ 22:03
wonder how it would compare if i didn't do return_val -= number all the time 22:04
and just put that value like how it is in the table
timotimo you totally could 22:05
samcv how to best inspect the binary file?
timotimo i used "objdump -d" to get that piece of assembly up there
section .main is the interesting one in our case i think
samcv great 22:06
timotimo, gist.github.com/samcv/d246759164a5...671ba8680d 22:07
am i right that this is all main gist.github.com/samcv/d246759164a5...sm-L36-L64 22:08
that's it?
looking at get_bitfield_offset right now
it doesn't seemed too optimized 22:09
though i don't use get_bitfield_offset in the file i compiled
but it seems to have generated the function anyway?
timotimo yeah 22:10
if you declare it "static" it can discard it, i think
samcv ok i put objdump in intel notation. much better 22:11
timotimo hehe.
samcv but i can't find get_offset_new 22:13
well not after i marked it const static
gist.github.com/samcv/d246759164a5...-asm-L4890 this was it before
timotimo that looks kinda good? 22:14
samcv don't recognize all of those operations 22:15
timotimo, so is it going through all the cp's in order?
i mean. the data structure it's a for loop
timotimo um, i think it does? 22:18
samcv but in this, that function is totally gone gist.github.com/samcv/70d98054b424...6c7782d887 22:19
get_offset_new that is
timotimo um, so, what's the question? 22:20
samcv sorry hold on
timotimo i'm only faking my way through the assembly-related questions, you know? :)
samcv that's ok
jnthn wanders off to rest; will look at that repeat bug tomorrow if nobody gets to it overnight 22:21
o/
timotimo gnite jnthn!
i don't know about a repeat bug?
samcv it calls get_bitfield_offset even though i don't call it in main
main calls it i mean. that makes no sesne 22:22
unless it's an old version. sec
timotimo i'll go ahead and commit the strand count fix in repeat, btw
probably an old version then
samcv no i recompiled and it's still there that's odd 22:23
ohhh i know why 22:24
dumb
Geth MoarVM: 775af411be | (Timo Paulssen)++ | src/strings/ops.c
fix GC problem in string repeat op

it set up the number of strands to be 1, but it didn't fill the strands array with valid data. after that, it could get into GC from collapse_strands, where it would then try to follow pointers from the strands array, thus panicking.
  samcv++ for the code that triggered this, dogbert17++ and jnthn++
for hunting and fixing respectively		 22:25
timotimo i should concentrate on the weekly for now
samcv kk 22:26
yeah if i put const static on get_bitfield_offset it doesn't compile it in when i don't use it
timotimo cool 22:27
samcv and gist.github.com/samcv/3a0e5115bfe5...-asm64-L36
timotimo i was worried i might have confused that with something else
samcv wtf is here
not sure where it's getting the result from
timotimo doesn't seem to do anything much 22:28
have you tried single-instruction-stepping through the code with gdb?
samcv ok accidently commented something
no, how should i do that
or do you just mean setting a break and going line by line
or however it goes 22:29
just normal stepping right?
timotimo it jumps into the .plt section, which i think is for stuff that'll get rewritten when dynamically loading? perhaps?
no, per assembly instruction
i think it's "stepi"
i forget how to get gcc to output assembly properly for your current function 22:30
PLT stands for Procedure Linkage Table which is, put simply, used to call external procedures/functions whose address isn't known in the time of linking, and is left to be resolved by the dynamic linker at run time.
samcv ok here's actual main gist.github.com/samcv/748cea9beae1...-asm64-L35
timotimo so it jumps into that .plt where at the moment of objdumping it's just nops and such
samcv but i can't find the function. hm 22:31
timotimo but the linker will have put proper jumping instructions there to get to your printf and such
samcv but it def works
i do see the sorted table, so it must be inlining it
lol in gdb, it doesn't let me step by line at all. must be totally optimized or whatever 22:46
22:54 pyrimidi_ joined
timotimo perhaps 23:02
samcv so it looks mostly the same even when it depends on argv 23:05
23:06 agentzh 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!