|
01:11
zostay joined
|
|||
| zostay | hoelzro: i might have a better test for the async crash you tried to help me with before | 01:17 | |
| hoelzro | zostay: interesting | 01:18 | |
| timotimo | well, then, share it with us! :) | 01:20 | |
| zostay | so, i was running a different test from you the whole time :-$ | ||
| i forgot to push the last commit | 01:21 | ||
| so... it's pushed now | |||
| clone github.com/zostay/HTTP-Supply/ and run: perl6 -Ilib t/http-1.0.t | 01:23 | ||
| the first test runs fine, but the second run chokes | |||
| anyway, putting kiddos to bed, biab | |||
| hoelzro builds a fresh rakudo | |||
| zostay: when you say it chokes...do you get a crash? | 01:29 | ||
| I'm just getting test failures | |||
| zostay | zsh: abort perl6 -Ilib t/http-1.0.t | 01:49 | |
| all tests should be passing | 01:50 | ||
| my first run went fine, but the second failed with an abort | |||
| hoelzro | zostay: which OS are you on? | 01:52 | |
| timotimo | .o( and what exact rakudo, nqp, and moarvm versions ) | 01:57 | |
| bbl | |||
| zostay | i built a recent rakudobrew in the last couple days, building again right now, but this has been very consistent for me on this laptop and on a linux vm | 01:59 | |
| happening on a brand new fresh build of nom/master/master just now | 02:04 | ||
| i am gettng completely different behavior on my linode though.... hmmm | 02:09 | ||
| hoelzro | zostay: which OS do your laptop and linux VM run? | 02:17 | |
| zostay | aha, there we go... it was missing test data :-$ | ||
| hoelzro | that fixed it? | ||
| zostay | no, that made linode repeat the problem i was having rather than test failures | 02:18 | |
| now linode aborts | |||
| hoelzro | ahhh | ||
| zostay | so, if you try a fresh pull, maybe now you'll see it? | ||
| hoelzro tries | |||
| nope, tests all pass =/ | 02:19 | ||
| zostay | try it a second time | ||
| hoelzro | zostay: which linux distro(s) are you trying on | ||
| did | |||
| three times | |||
| zostay | it passes the first time, but fails the second and then after until the cache or whatever clears and try again later | ||
| hoelzro | I just tried it about ten times, all passed =/ | 02:20 | |
| zostay | OSX 10.11 is my laptop | ||
| the linode is: gentoo Linux 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015 Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz GenuineIntel GNU/Linux | 02:21 | ||
| the Linux VM is: Mint Mate Linux 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 GNU/Linux | 02:23 | ||
| hoelzro | hmm...pretty diverse | ||
| welp, I'll fire up a VM | 02:24 | ||
| hoelzro builds Rakudo on FreeBSD | 02:26 | ||
| I forgot how long interp.c takes to compile on clang =/ | 02:27 | ||
| zostay: I got it to abort! | 02:38 | ||
| I bet it's running out of fds | |||
| $ ulimit -a | grep file\ descriptors | 02:39 | ||
| -n: file descriptors 58284 | |||
| ok, so not likely =/ | |||
| zostay | \o/ | 02:40 | |
| hoelzro | yay, I got a stack trace | 03:03 | |
| pthread_mutex_destroy is failing (!?!) | 03:04 | ||
| failed to destroy mutex: Device busy o_O | 03:06 | ||
| sounds like the mutex is being free'd while locked? | 03:08 | ||
| yup | 03:11 | ||
| well, that ain't good. | |||
| ok, it turns out that the thread that's cleaning up the mutex has still locked it | 03:23 | ||
| which is...odd | 03:24 | ||
| ha! now that I added some printfs on Arch, it messed up the timing enough to cause the abort! | 03:51 | ||
|
04:08
geekosaur joined
04:11
geekosaur joined
|
|||
| hoelzro | zostay: when you get a chance, could you try with MVM_SPESH_DISABLE=1? | 04:26 | |
| that seems to fix it for me | |||
| it's a lock that's being locked via Lock.protect; it looks like it might be getting locked in a Promise vow as well | 05:13 | ||
| I'm off to bed; I'll dig in more tomorrow | |||
|
06:13
geekosaur joined
08:09
domidumont joined
|
|||
| zostay | hoelzro: thx... i tried MVM_SPESH_DISABLE=1 and it helps somewhat | 12:14 | |
| on OS X it gets to ok 24 instead of stopping after ok 20 | |||
| it doesn't make any difference on my linode | 12:15 | ||
| no difference on my linux vm either | 12:23 | ||
| a thread cleaning up in a bad state sounds exactly like what i found when i originally dug in with the debugger | 12:29 | ||
| but i am not familiar with mvm internals, so i really didn't know where to go with that | |||
|
12:38
cognominal joined
|
|||
| hoelzro | so I've been taking further stabs at the problem this morning | 14:14 | |
| it *looks* like Lock.protect is locking in some situations without an unlock | 14:15 | ||
| dalek | arVM/circular_outer_fixups: 4cef4ac | timotimo++ | src/core/bytecode.c: don't allow outer frames to create a circle there's a lot of potential for making the code cheaper |
14:16 | |
| timotimo | ^- i'm not sure, but i *think* we might only have to actually inspect frames that were "fixed up" | 14:19 | |
| hoelzro | yay, I was able to reproduce zostay's bug | 14:22 | |
| (in a standalone script) | |||
| timotimo | cool! | ||
| hoelzro | this line in Lock.pm irks me a bit: CATCH { nqp::unlock(self); } | 14:23 | |
| timotimo | hehehe | ||
| hoelzro | shouldn't it nqp::rethrow($_) after the unlock? | ||
| timotimo | it doesn't need to | ||
| hoelzro | or does it already because the exception isn't "handled"? | 14:24 | |
| timotimo | because there's no "default {...}" in there | ||
| hoelzro | ahhh, ok | ||
| timotimo | should, yeah | ||
| hoelzro | timotimo: does that apply to CONTROL as well? | ||
| timotimo | i think so | ||
| should be easy-ish to try | |||
| hoelzro | I think the bug is that CONTROL exceptions aren't caught, so no unlock happens | 14:25 | |
| timotimo | well, control exceptions are resumable | 14:29 | |
| that makes it very difficult to deal with them properly on a general basis | |||
| i don't think we have a phaser for "execute this code when the exception has been resumed", so we can't re-lock on resumption | 14:30 | ||
| and even then we'd have the lock briefly unheld while the code up the stack decides whether to resume or not | |||
| hoelzro | "Trying to unwind over wrong handler" weeeeeee | 14:32 | |
| hmm, I hadn't considered that | |||
| that makes this *much* more complicated =/ | 14:33 | ||
| timotimo | yes, very | ||
| hoelzro | guess I'll file an RT | 14:37 | |
| zostay: in case you want to track the issue: rt.perl.org/Ticket/Display.html?id=127865 | 14:43 | ||
| zostay | thx, so if it's a control exception that's blowing things up, maybe i can work around it by avoiding the control statement that tosses it? | ||
| timotimo | you might have to use .lock and .unlock manually perhaps :( | 14:44 | |
| hoelzro | I just don't know which lock protect is being called on =/ | 14:45 | |
| timotimo | then you can output the WHICH :) | ||
| hoelzro | that I've done, but I still don't know where it gets created in Perl 6 land =( | ||
| timotimo | oh | 14:46 | |
| zostay | yeah, that's what i was thinking... i don't mind putting in manual locks if it's temporary until you guys can think through to a gooder solution | ||
| timotimo | OK, in that case you can set breakpoints for the creation of a MVMLock or what it's called REPR | ||
| and print MVM_dump_backtrace(tc) in there | |||
| like, break the_line; commands; print MVM_dump_backtrace(tc); print the_address_of_the_lock; c; end | |||
|
14:47
camelia joined
|
|||
| zostay | if i can get this to work, i can try and sneak a p6sgi talk in at yapc | 14:47 | |
| rob, if you're coming to yapc, i will happily buy you lunch for digging that out | 14:56 | ||
| hoelzro | ahhhh | 14:57 | |
| good idea timo | |||
| zostay: thanks, but sadly I don't think I'll be making to yapc this year =( | 14:58 | ||
| timotimo++ # backtrace tips | 15:03 | ||
| timotimo | :) | ||
| inspired by how helgrind works | |||
| it'll also tell you the stack trace of where something got created for every single lock-like thing whenever it's mentioned somewhere | 15:04 | ||
| hoelzro | neat | ||
| interesting...it's the SupplyBlockState from Supply.tap | 15:06 | ||
| well, something with SUPPLY, anyway | 15:08 | ||
| hoelzro goes out for coffee | 15:09 | ||
|
16:54
zakharyas joined
16:56
lucasb joined
|
|||
| lucasb | libuv 1.9 was releases 2 days ago | 16:56 | |
| can we get that for the release next week? | |||
| changelog is here: github.com/libuv/libuv/releases/tag/v1.9.0 | 16:57 | ||
| timotimo | how far behind are we currently? | 17:00 | |
| lucasb | I think moar is at 1.8 | 17:01 | |
| timotimo | ah, good, so the changelog is "exhaustive" for us | 17:02 | |
| anything in particular that stands out to you? | 17:04 | ||
| lucasb | I don't know if any bug fixed in libuv affected moarvm. I suggested just for the sake of keeping things updated :) | 17:05 | |
|
17:09
geekosaur joined
17:13
geekosaur joined
|
|||
| timotimo | yes, yes | 17:13 | |
| but i'm an excitement driven developer :P | |||
|
17:16
domidumont joined
|
|||
| jnthn | I tend to feel a bit safer bumping versions of deps just *after* a release so we maximize testing time before the next one :) | 18:13 | |
| Though it looks like a fairly low-risk bump in this case | |||
|
18:34
vendethiel joined
|
|||
| timotimo | jnthn: +1/-1 on building an op that turns a buffer like VMArray into a Big Integer directly, and perhaps the other way around, too? | 18:42 | |
|
19:37
FROGGS joined
|
|||
| jnthn | timotimo: As in, just using the bits in the array? | 19:45 | |
| Also: use case? How will it be used from Perl 6? | 19:58 | ||
| timotimo | building random big integers | 20:06 | |
| we don't have a way to add two big buffers together and have it proper carry ... without building that yourself | 20:08 | ||
|
20:15
TimToady joined
20:28
zakharyas joined
20:39
Ven joined
|
|||
| timotimo | i'll try to rebuild moar and see if the resume commandline from the readme works as intended | 21:15 | |
| i'm looking at output in a format that i don't recognize ... well, it'll be fine. everything'll be fine. | 21:23 | ||
| "warning: no new instrumentation output, test case may be useless" - i expect this happens when a bug that had been the basis for a test case to be created was fixed in the mean time and no longer causes a crash | 21:27 | ||
|
21:51
vendethiel joined
|
|||
| timotimo | uh oh | 21:53 | |
| as expected, i messed it up somehow :) | |||