| MasterDuke | my branch names keep getting longer and longer | 00:16 | |
| timotimo | don't use the x operator for your branch names :D | ||
| MasterDuke | and then i try and distill them down to a title for the commit, that takes longer than the actual coding! | 00:18 | |
| timotimo | yeah, naming things ... ugh | 00:19 | |
|
00:22
agentzh joined
|
|||
| MasterDuke | .tell samcv it appears using nqp::getstrfromname in Rakudo broke the JVM build: Stage jast : Error while compiling op getstrfromname (source text: "nqp::getstrfromname(nqp::atpos(names, $i).trim)"), no registered operation handler | 02:02 | |
| yoleaux2 | MasterDuke: I'll pass your message to samcv. | ||
| samcv | hey MasterDuke | 02:03 | |
| yoleaux2 | 02:02Z <MasterDuke> samcv: it appears using nqp::getstrfromname in Rakudo broke the JVM build: Stage jast : Error while compiling op getstrfromname (source text: "nqp::getstrfromname(nqp::atpos(names, $i).trim)"), no registered operation handler | ||
| samcv | it compiled the last time i checked | ||
| maybe something changed? i know i compiled jvm when i added that in | |||
| which file is it failing the build on MasterDuke ? | |||
| MasterDuke | gist.github.com/MasterDuke17/a2de1...ecf8e72d11 | 02:04 | |
| at HEAD on nom | |||
| did a `make realclean` and restarting the build | 02:06 | ||
| a `git grep getstrfromname` in Rakudo and NQP don't return any hits in .java files | 02:07 | ||
| samcv | yeah cause in has a #?if moar | 02:13 | |
| MasterDuke | src/core/Str.pm:1368: isn't wrapped in `#?if moar` | 02:17 | |
| commit 5c1761a6486317da6cef52bace348d3d5f350676, Author: Zoffix Znet [email@hidden.address] | 02:19 | ||
| IOninja: github.com/rakudo/rakudo/commit/5c...3d5f350676 from the JVM build. nqp::getstrfromname isn't implemented for the JMV. for reference, it's wrapped in a `#?if moar` here: src/Perl6/Actions.nqp:9254: | 02:21 | ||
| *broke the JVM build | |||
| oops, that was supposed to be in #perl6-dev | |||
|
02:27
agentzh joined
02:48
ilbot3 joined
|
|||
| samcv | ah ok so it wasn't me then :P | 02:48 | |
|
06:55
domidumont joined
07:11
brrt joined
07:20
agentzh joined
|
|||
| brrt | good * #moarvm | 07:43 | |
| yoleaux2 | 3 Mar 2017 23:07Z <MasterDuke> brrt: fyi, if you're interested in the JIT bug, there's a bunch of discussion here: irclog.perlgeek.de/moarvm/2017-03-03#i_14196620 | ||
| samcv | hey brrt | 07:44 | |
|
07:46
ggoebel joined
|
|||
| brrt | hey samcv, MasterDuke | 07:47 | |
| samcv | :) | ||
| happy brrthday | 07:48 | ||
| brrt | i'll take a look at it, but i think the problem is that the semantics of div had been changed | ||
| thank you | |||
| (how did you…?) | |||
| samcv | it's not your birthday is it? | ||
| i just thought it was clever wordplay | |||
|
09:07
domidumont joined
09:14
sivoais joined,
domidumont joined
|
|||
| brrt | well, it was my birthday just two days ago | 10:02 | |
| so it was recent enough that i let it ocunt | |||
| jnthn | Happy belated birthday :) | ||
| brrt | thanks :-) | ||
| jnthn | morning #moarvm o/ | ||
| brrt | i'll try to take a look at the JIT div bug then.. | ||
| but i suppose this resolves to native int div, doesn't it? | 10:03 | ||
| jnthn | brrt: So far as I've followed | 10:09 | |
| timotimo | habby birrthday, belatedly! | 10:10 | |
| is that jit div bug the one where a patch to infix:<div> makes things randomly fail unless you turn off jit? | 10:11 | ||
| brrt | well, not randomly | 10:12 | |
| i have a test case :-) | |||
| timotimo | oh, ok, that's good, then. | ||
| dogbert17_ | happy birthday brrt | 10:20 | |
| dogbert17_ suudenly remembers that he promised to write a MoarVM issue, gets to work ... | |||
| tada github.com/MoarVM/MoarVM/issues/547 | 10:31 | ||
|
11:16
brrt joined
|
|||
| brrt | (because of the XOR, that is surprisingly complex in assembly language) | 11:28 | |
| that said, it appears it's 'always' been this way | 11:31 | ||
| at least, before the JIT was there | 11:32 | ||
| so it's a dumb codegen bug | |||
| samcv | morning jnthn | 11:47 | |
| jnthn | o/ samcv | 11:48 | |
|
12:06
geekosaur joined
12:29
domidumont joined
12:47
GK__1wm___SU joined
13:15
domidumont joined
13:57
KDr2 joined
14:16
El_Che joined
|
|||
| El_Che | www.eclipsecon.org/na2016/sites/de...ntimes.pdf <-- camelia on page 7 | 14:16 | |
| crossposting from #perl6 | 14:17 | ||
|
15:18
brrt joined
16:53
domidumont joined
17:37
Ven joined
17:38
domidumont joined
18:18
FROGGS joined
18:38
Ven joined
18:48
zakharyas joined
19:27
dogbert17 joined
|
|||
| dogbert17 | my $waiter = Proc::Async.new("echo", :args<Hello World>).start; await start { await $waiter } | 19:37 | |
| ^^^ the above piece of code has a tendency to hang, how would one go about debugging this, btw, this is RT #122709 | 19:38 | ||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=122709 | ||
| jnthn | What happens if you stick "use v6.d.PREVIEW;" at the start of it? | 19:40 | |
| dogbert17 | will try | ||
| seems to work a lot better at first glance | 19:42 | ||
| 200 runs with no problem using 'use v6.d.PREVIEW;' | 19:43 | ||
| jnthn | Nice, figured that'd sort it out | ||
| The reason it ends up in bother at the moment is due to a scheduler bug of some sort | 19:44 | ||
| It doesn't start enough threads | |||
| dogbert17 | mysterious | ||
| nwc10 | jnthn: new! never seen before! paste.scsys.co.uk/557403 | ||
| jnthn | Our scheduler is...uh...not very smart. | 19:45 | |
| nwc10 | I've not even seen the error message "runtime error: member access within null pointer of type 'struct MVMSTable'" before | ||
| jnthn | o.O | ||
| Wow | |||
| dogbert17 | but oftentimes it does start enough threads | 19:46 | |
| jnthn | Too bad it doesn't have more info.... | ||
| timotimo | that might just be diagnostics that asan didn't know how to output before? | ||
| jnthn | dogbert17: Yeah, it almost always does, I forget what was special about this case | ||
| nwc10 | it's still gcc 4.9 from May 2014 | 19:47 | |
|
19:48
El_Che left
|
|||
| dogbert17 | hmmgdb doesn't want to play ball either | 19:49 | |
| [Coke] wondered for a second if hmmgdb was a special build. :) | 19:54 | ||
| dogbert17 | jnthn, FWIW strace write stuff like this when the program hangs 'futex(0xa9ab618, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)' | ||
| :) | |||
| jnthn | Yeah, I think I hunted that one down far enough that I realized I'd leave it until I got to giving the scheduler a larger overhaul | 19:57 | |
| It just doesn't shart enough threads | 19:58 | ||
| *start | |||
| o.O | |||
| And there's no monitoring thing to detect lack of progress and make adjustments | |||
| dogbert17 | thx for the explanation, I'll look for something more interesting then and leave the bug to the overhaul | 20:00 | |
| btw, any ideas how to get further with the harness6 problems? | 20:01 | ||
| jnthn | Not really, though it appears we have 3 distinct problems at this point | 20:02 | |
| dogbert17 | my own attempts have failed miserably :) | ||
| jnthn | One in spesh that nwc10 just caught in ASAN, one involving an over-shared deocder or something that appears to be that at least (this one is likely the most tractable to solve), and then the one that shows up when we GC a corrupt P6bigint | 20:03 | |
| dogbert17 | I believe that you mentioned code that would stress the decoder paths. What would such code look like? | 20:04 | |
| or might there be a specific spectest file which inadvertently stresses it | 20:05 | ||
| jnthn | Just doing a load of Proc::Async processes concurrently in a loop should do it | ||
| Like spawn 10 procs taht will produce a bunch of output, tap them in character mode (the default), let them all exit, repeat. | |||
| dogbert17 | interesting | 20:06 | |
| jnthn | That's basically what harness6 is doing at the end of the day ;) | 20:07 | |
| Spawning 10 test files | |||
| And reading their outputs | |||
| Where 10 is actually TEST_JOBS | 20:08 | ||
| Which is 8 for me | |||
| dogbert17 | ok, I'll see what I can do ... | ||
| jnthn | Cool, thanks | ||
|
20:09
Ven joined
|
|||
| dogbert17 | jnthn: do you mean code like this, but with more procs? gist.github.com/dogbert17/037f464c...95fae63ed9 | 20:12 | |
| jnthn | Yeah :) | 20:16 | |
| walk; bbiab | 20:17 | ||
|
20:24
vendethiel joined
21:17
Ven joined
21:25
Ven joined
|
|||
| dogbert17 | jnthn, it works | 21:27 | |
| jnthn | Works as it reproduces the bug? :) | 21:29 | |
| Or works as in doesn't reproduce the bug? | |||
| dogbert17 | yes, after a while :) reproed | 21:30 | |
| jnthn | hah, nice! | ||
| timotimo | jnthn: did you have an opinion on whether isbig_I should be used to check for specific bounds? | ||
| dogbert17 | do you see anything here gist.github.com/dogbert17/433e0f6c...7c88729402 | 21:31 | |
| jnthn | No; what's the 0xb7fdccb0 that all the rest are in? Presumably shifting concblockingqueue? | 21:34 | |
| dogbert17 | I can't 'bt' those | 21:35 | |
| jnthn | odd | ||
| dogbert17 | well, at least I have some crappy code if anyone else want to give it a go :) | 21:36 | |
| this is what I get: | 21:37 | ||
| (gdb) t 2 | |||
| [Switching to thread 2 (Thread 0xb59a2b40 (LWP 12881))] | |||
| timotimo | we might be able to figure out where those code segments are from /proc/self/maps or something? | ||
| dogbert17 | #0 0xb7fdccb0 in ?? () | ||
| (gdb) bt | |||
| Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x2903: | |||
| jnthn | What if you type frame 1, frame 2, etc? | 21:40 | |
| dogbert17 | will try | 21:41 | |
| jnthn | Something very odd is going on, anyway | 21:42 | |
| dogbert17 | indeed, could be something with my installation which makes gdb miserable | ||
| jnthn | Anyway, I'll certainly have a crack at reproducing this locally with your repro code :) | 21:43 | |
| Tomorrow or Wednesday :) | |||
| dogbert17 | coool | 21:44 | |
| I'll update my gist | |||
| will give ASAN a go, perhaps things are horribly corrupted | |||
|
21:55
Ven joined
23:02
ggoebel joined
|
|||