|
01:27
MasterDuke_ joined
|
|||
| MasterDuke_ | timotimo: i thought this looked interesting: ourmachinery.com/post/virtual-memory-tricks/ | 02:13 | |
| particularly the idea to use a virtual memory allocator to help debugging | |||
| think that's something moarvm could use? | 02:14 | ||
| timotimo | reminds me a bit of libefence | 02:21 | |
| MasterDuke_ | isn't that a bit annoying to use? | 02:31 | |
| timotimo | don't think so? | 02:38 | |
| don't you literally just LD_PRELOAD it? | |||
| i'm going to sleep! seeya :) | 02:41 | ||
|
02:57
ilbot3 joined
03:10
colomon_ joined
03:50
colomon joined
06:34
Guest26563 joined
06:59
domidumont joined
07:05
brrt joined
|
|||
| brrt | good * #moarvm | 07:05 | |
|
07:05
domidumont joined
|
|||
| samcv | good * brrt | 07:10 | |
| brrt | ohai samcv | 07:11 | |
| what's up | |||
| samcv | not much. trying to fix some sprintf things in nqp | 07:14 | |
| really odd. %d returns the number with padding from the method in the grammar but %b doesn't. and that's odd | 07:15 | ||
| since i'm not sure where it's adding the padding on. and as a result it returns 0000-1000 for negative numbers if you use padding | 07:16 | ||
|
07:44
domidumont joined
08:34
zakharyas joined
09:36
brrt joined
09:45
benchable6 joined,
statisfiable6 joined,
unicodable6 joined
09:49
dogbert2 joined
|
|||
| bartolin | samcv: I'm not sure if it is relevant, but I started a branch back in 2015 where I tried to improve the padding for %b. I didn't follow up, though ... github.com/perl6/nqp/tree/sprintf | 09:54 | |
| samcv | heh. and the test fixes i just made independently. will look at it though :) | 09:55 | |
|
09:57
domidumont joined
|
|||
| brrt | i've been trying to put large constants (i.e. pointers) in a separate table | 09:59 | |
|
10:01
AlexDaniel` joined
10:03
greppable6 joined,
squashable6 joined,
coverable6 joined,
bloatable6 joined
10:11
robertle joined
10:14
zakharyas joined
|
|||
| brrt | hmm, question | 10:21 | |
| nm, answer | 10:22 | ||
| i'm wondering whether i should split a large constants table from the constant pointers | |||
| the only purpose i can find for that would be to have large constants bigger than 8 bytes | 10:28 | ||
| samcv | brrt: what are these constants used for and how often are they used | 10:29 | |
| brrt | the current use is to have pointers | 10:30 | |
| so 8 bytes on x86-64 | |||
|
10:30
ilmari[m] joined
|
|||
| samcv | uh oh | 10:30 | |
| Error in `/home/samantha/perl6/bin/moar': corrupted double-linked list: 0x00007f7fbc0fe920 *** | |||
| never gotten this before... | 10:31 | ||
| brrt | absolute power corrupts | ||
| samcv | double power corrupts absolutely? | 10:32 | |
| idk sounded better in my head | |||
| backtrace is here gist.github.com/b0f777b4c21ddea542...a93396019a | 10:33 | ||
| looks like it happening during bind_key | 10:34 | ||
| and i'm getting a failure in IO-Socket-Async.t | 10:36 | ||
| Unhandled exception in code scheduled on thread 4 (and for 6 too) then too few positionals passed | |||
| let me try a make realclean | |||
| nope still failing… | 10:37 | ||
|
10:37
AlexDaniel joined
10:38
stmuk joined
11:11
AlexDaniel joined
11:46
brrt joined
13:31
domidumont joined
13:43
dogbert17 joined
|
|||
| dogbert17 | I haven't seen this before: MoarVM panic: non-AsyncTask fetched from eventloop active work list | 13:43 | |
| timotimo | but it doesn't output what it is? that's a simple fix, just put the debug name (MVM_6model_get_debug_name(tc, whatever)) | 13:45 | |
| dogbert17 | I'll see if I can repro it under gdb, all I have so far is that it happened while running test 62 in t/spec/S17-supply/syntax.t | 13:47 | |
| that test has the following text 'CLOSE phaser sees correct outer scope' | 13:48 | ||
| [Coke] | didn't jnthn -just- touch that? | 13:49 | |
| timotimo | yeah | 13:50 | |
| gist.github.com/timo/f9fd9cf97f99d...2eded46972 - dogbert17 | 13:54 | ||
| dogbert17 | sigh, while running it in gdb I got a SEGV while running test 68 | 13:55 | |
| jnthn | Yes, I fixed that issue yesterday and added the test | ||
| dogbert17 | timotimo: thanks, I'll add it | ||
| here's the SEGV, while running test 68, gist.github.com/dogbert17/178c6c6c...075d9ac17c does anything stand out? | 13:57 | ||
| timotimo | you surely got jnthn's latest moarvm commit as well? | 13:58 | |
| oh, not a moarvm commit | |||
| dogbert17 | ... built on MoarVM version 2017.10-57-gd257df23 | 13:59 | |
| btw, both problems turned up while the system was under som stress | 14:00 | ||
| *some | |||
|
14:04
zakharyas joined,
domidumont joined
|
|||
| dogbert17 trying timotimo's clever patch | 14:05 | ||
| and the result is: MoarVM panic: non-AsyncTask fetched from eventloop active work list: was VMNull | 14:06 | ||
| timotimo | that's the most boring way to have that happen | 14:07 | |
| dogbert17 | :) | 14:08 | |
|
14:10
AlexDaniel joined
|
|||
| dogbert17 | jnthn, timotimo: what about this gist.github.com/dogbert17/71d071ab...67d6b4bd0f | 14:11 | |
|
14:26
yoleaux joined
|
|||
| dogbert17 | seems as if that test can fail in a few different ways, i.e. 'MoarVM panic: non-AsyncTask fetched from eventloop active work list' or 'MoarVM panic: use of invalid eventloop work item index -1' or SEGV at | 15:16 | |
| 0xb7bb9b49 in setup_work (tc=0xb36eb448) at src/io/eventloop.c:15 | |||
| 15 MVMConcBlockingQueue *queue = (MVMConcBlockingQueue *)tc->instance->event_loop_todo_queue; | 15:17 | ||
| dogbert17 continues his ramblings | 15:31 | ||
| it turns out that valgrind has some comments wrt this test: gist.github.com/dogbert17/3a7a6dba...47a5a7e49c | 15:33 | ||
| timotimo | that last one looks a bit like a missing MVMROOT | 15:45 | |
| dogbert17 | yeah, perhaps that one is the root :) of all problems above | 15:49 | |
| but how do you find them | |||
| timotimo | gc torture can help narrow it down | 15:50 | |
| dogbert17 | I can try that | ||
|
15:54
brrt joined
|
|||
| dogbert17 | the first invalid read is very consistent, shows up every time | 15:55 | |
| Geth | MoarVM: d38519364e | (Timo Paulssen)++ | src/6model/reprs/MVMIter.c Don't segfault when MVM_iter on type object |
16:05 | |
| dogbert17 | timotimo: did you find something? | 16:07 | |
| timotimo | no, that's unrelated | 16:11 | |
| dogbert17 | timotimo++ anyway :) | 16:12 | |
|
16:37
brrt joined
17:34
domidumont joined
17:45
domidumont joined
17:52
releasable6 joined
|
|||
| ugexe | what is MoarVM/lib/MAST/Ops.p6 for? it says at the top that tools/update_ops.p6 updates it but that doesn't seem to be the case (so maybe Ops.nqp took its place?) | 18:04 | |
|
18:04
zakharyas joined
|
|||
| ugexe | also whats the best way to build a rakudo against a moarvm with a new op? usually I build rakudo at its latest commit and edit MoarVM files inside there (doing a `make install` will put everything in the proper spot). but trying to build nqp i'm now getting "operand type 32 does not match register type 56" despite what I thought was thorough make cleans | 18:10 | |
| [Coke] | ugexe: you can explicitly configure it with --gen-moar=master or --gen-moar=<sha1> | ||
| then you don't have to do any of the edits yourself. | |||
| ugexe | the edits are source code edits... i do wants those :) | 18:11 | |
|
18:55
AlexDaniel joined
19:05
AlexDani` joined
19:23
Ven joined
19:25
Ven_ joined
20:37
Ven joined
|
|||
| jnthn | ugexe: You'll have to rebuild Rakudo too if you add new ops | 20:49 | |
| ugexe | if I put the op to the bottom of oplist it works, but if i put it in the middle (grouped with getpid) it doesn't | ||
| should i be trying to group it like that? | |||
| jnthn | The docs at the top of the oplist file explain where to add them | 20:50 | |
| ugexe | yeah i guess thats better instructions than git history heh | 20:51 | |
| jnthn | Don't write docs, and everyone asks for the docs. Do write docs, and nobody reads the docs. :P | 20:52 | |
| nine doesn't see himself as nobody. Well not all the time anyway ;) | 20:53 | ||
| jnthn | :-) | 20:55 | |
| Usually the size of the "everybody" asking for docs is 1 or 2 people also ;) | 20:56 | ||
|
20:56
Ven_ joined
|
|||
| nine | jnthn: that's a bug, isn't it? github.com/MoarVM/MoarVM/blob/mast...late.c#L73 | 20:57 | |
| jnthn | ooh | 20:59 | |
| Yes, it should be append_to->next = ann; | |||
| nine | And append_to may even be NULL | ||
| So if (append_to) append_to->next = ann; else prev->annotations = ann; | 21:00 | ||
| jnthn | That also | ||
| nine | Kinda ironic to see such complex machinery working but finding the bug in code for appending to a linked list. Which is literally a data structures 101 beginner exercise :D | 21:01 | |
| Nicely demonstrates how we're all human I guess :) | 21:02 | ||
| jnthn | Indeed. Also why code review is a really good idea. | 21:03 | |
| nine | Unfortunately it doesn't bring me closer to why removing a useless goto carrying a DEOPT_INLINE annotation causes breakage when that annotation is never used anywhere | 21:08 | |
| jnthn | Does the annotation get moved? | 21:09 | |
| The inline annotations are really important | |||
| nine | Now that the bug is fixed, yes. But it shouldn't make a difference. Not a single code path that checks for that annotation is actually hit even when the goto's still there. | ||
| jnthn | Hmm | 21:10 | |
| timotimo | isn't it still used in the code gen to build the handler/uninline table? | ||
| nine | The case MVM_SPESH_ANN_DEOPT_INLINE: in src/spesh/codegen.c:116 never gets triggered in the test case | 21:11 | |
| The only logical conclusion I can see is that it's not the DEOPT_INLINE annotation that's important, but the goto itself. The annotation is just the last thing that would keep the goto from getting eliminated. | 21:18 | ||
| So something seems to be depending on an inlined basic block always being entered through a goto. | 21:19 | ||
|
21:36
Ven joined
21:56
Ven_ joined
22:16
Ven_ joined
22:36
Ven joined
|
|||
| jnthn | nine: github.com/MoarVM/MoarVM/blob/mast...opt.c#L118 | 22:40 | |
|
22:56
Ven_ joined
23:16
Ven_ joined
|
|||
| Geth | MoarVM: ugexe++ created pull request #747: Put op in same order relative to oplist |
23:23 | |
| MoarVM: ugexe++ created pull request #748: Add getppid op |
23:26 | ||
| jnthn | .oO( But is PR 747 jumbo? :) ) |
23:36 | |
|
23:36
Ven joined
|
|||
| jnthn | ugexe: fwiw, I'm in favor of #747 for the same of humans; I suspect compilers are smart enough (and I think somebody here measured that in the past). | 23:36 | |
| *the sake of | 23:37 | ||
| ugexe | that was just a cut and paste from the comments/docs... now I have an excuse for not reading them | 23:40 | |
| jnthn | ;) | 23:41 | |
| Geth | MoarVM: 1a8664b2dc | (Nick Logan)++ (committed using GitHub Web editor) | src/core/interp.c Put op in same order relative to oplist The ops should be in the same order here as in the oplist file, so the compiler can can optimize the switch properly. |
23:42 | |
| MoarVM: 2ca7e8587b | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/interp.c Merge pull request #747 from ugexe/patch-3 Put op in same order relative to oplist |
|||
| jnthn | Aww. So I merged that and now 748 has a conflict. | ||
| Which was, I guess predictable. | |||
| ugexe | heh yeah i figured | ||
| i forced pushed the merge conflict fix to my branch | 23:49 | ||
| jnthn | Cool. I'm off to rest now; I'll look at it in the morning :-) | 23:50 | |
| ugexe | see ya later | 23:51 | |