Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-02-13

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

All times shown according to UTC.

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

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