00:13
cognominal joined
01:34
evalable6 joined
01:55
ilbot3 joined
02:11
releasable6 joined
|
|||
ugexe | libuv 1.15.0 released, which includes the stack size fix for musl | 03:47 | |
github.com/libuv/libuv/issues/1507 | 03:51 | ||
04:38
evalable6 joined
|
|||
samcv | good hi | 04:51 | |
05:57
evalable6 joined
07:10
domidumont joined
07:15
domidumont joined
08:04
Voldenet joined
08:41
dogbert17 joined
|
|||
lizmat | good *, #moarvm | 09:31 | |
09:31
rba_ joined
|
|||
lizmat | .ask jnthn should the BUILDPLANs of nqp match the layout of Perl 6 or not? currently not matching is the underlying cause of RT #132236 | 09:32 | |
yoleaux | lizmat: I'll pass your message to jnthn. | ||
synopsebot | RT#132236 [open]: rt.perl.org/Ticket/Display.html?id=132236 [REGRESSION] Meta object construction | ||
09:46
rba joined
10:02
rba_ joined
10:16
rba joined
10:31
rba_ joined
10:46
rba joined
11:01
rba_ joined
11:03
rba joined
|
|||
timotimo | ugexe: i feel a bit bad now. we were totally able to do spesh inside the limit imposed by musl | 11:22 | |
and they fixed it for us in the mean time. maybe i should have told them we already made it :| | |||
MasterDuke | timotimo: interesting, my string fsa branch is panicking on freeing "&infix:<−>" | 11:49 | |
even though body.num_graphs == 10 and body.storage_type = MVM_STRING_GRAPHEME_32 | 11:52 | ||
m: say "&infix:<−>".chars | |||
camelia | 10 | ||
timotimo | does it use a buffer that had more space in it? | 11:53 | |
MasterDuke | yeah | 11:57 | |
got 40 (which equal to 10*sizeof(MVMGrapheme32)), expected 48 | 11:59 | ||
alloced at utf8.c:183 | 12:00 | ||
MVM_string_utf8_decode | |||
i'm seeing what happens if i remove this github.com/MoarVM/MoarVM/blob/mast...tf8.c#L293 if and just always realloc | 12:05 | ||
oh, that succeeds | 12:06 | ||
rakudo's `make m-test` passed | 12:13 | ||
spectest did not | 12:14 | ||
Invalid read of size 8 at 0x504A3E4: MVM_fixed_size_free (fixedsizealloc.c:277) by 0x5076B66: gc_free (MVMString.c:87) ... Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd | 13:02 | ||
timotimo | sounds like you tried to fixed_size_free a null pointer | 13:07 | |
because 0xfffffffffffffff8 is just -8 | |||
MasterDuke: ^ | |||
MasterDuke | probably | ||
unfortunately your valgrind script isn't firing, so i don't know where it came from | 13:08 | ||
timotimo | it's very possible to fix that! | ||
just put a null pointer check in front and do "the same thing" as when the size doesn't match | 13:09 | ||
wait | |||
actually, there's no information we could get here | |||
we'd have to inspect the address of the variable that was passed to the free function i guess | 13:10 | ||
MasterDuke | right, cause this is where it's segving: if (dbg->alloc_size != bytes) { | 13:11 | |
timotimo | MasterDuke: what pieces of code exist that can set the pointer you were trying to free to zero? | 13:34 | |
MasterDuke | lots! | 13:35 | |
it's gcing a string | |||
gist.github.com/MasterDuke17/5ca4c...c515c8ab76 full valgrind output | 13:36 | ||
timotimo | oh, do we set the pointer to null when gc_free is called on the string? | ||
hm. if we gc_free the same string multiple times, or if we share buffers between multiple strings, we'd have had "double free" errors before in this situation | 13:37 | ||
MasterDuke | it's just a free of str->body.storage.any and str->body.num_graphs = str->body.num_strands = 0; | 13:39 | |
in MVMString's gc_free | 13:41 | ||
timotimo | hm. what is the size "to be freed", ooc? maybe it is actually zero | 14:11 | |
it could very well be we've so far been freeing zero-length fields without erroring out | 14:12 | ||
is MVM_fixed_size_alloc ever called with a size of 0? | 14:23 | ||
MasterDuke | timotimo: yep, bytes=0 when it dies | 14:24 | |
timotimo | aha! | ||
and do we allocate something with size 0 ever? | 14:25 | ||
MasterDuke | don't know. gotta afk for a while, will work some more on it when back (unless you've fixed everything in the meantime of course) | 14:26 | |
timotimo | hm but if we allocate something with size 0 in the fsa debug mode we'll actually create something of size 8 | ||
it's all in your branch? | |||
14:29
evalable6 joined
|
|||
MasterDuke | yep | 14:29 | |
with a recent commit just pushed | 14:30 | ||
15:31
dogbert17 joined
15:34
leont joined
16:39
wander4096 joined
|
|||
ugexe | timotimo: on the bright side 1.50 also has an improvement for file watching on osx to not use a handle per file, so maybe that flopping osx test will be fixed. i will have to check | 16:54 | |
hmm also exposed libuv api for recursive mutex on linux | 16:57 | ||
17:21
domidumont joined
|
|||
MasterDuke | timotimo: interesting, i added some fprintfs to fixed_size_(re)?alloc in case the bytes are 0 and it dies in the free, but those never print | 17:31 | |
17:33
timo2 joined
17:39
timo3 joined
|
|||
jnthn | ugexe: I think we could still do with bumping the stack size for the specializer thread; I suspect there are other places where, at the moment, we only just squeak by due to use of recursive algorithms. So we can still make some use of it. :) | 17:41 | |
yoleaux | 6 Oct 2017 15:31Z <Zoffix> jnthn: when you get a chance, take a look at t/spec/S17-channel/stress.t It seems to take a lot longer than before. My pre-moar-bump stresstest time was 160s, post-bump it's 261s with the stresstest sitting on that test file | ||
7 Oct 2017 10:58Z <lizmat> jnthn: would it make sense to also auto-generate BUILD_LEAST_DERIVED ? | |||
7 Oct 2017 20:34Z <bartolin> jnthn: if you have a few minutes to look at my try to implement killprocasync on jvm: github.com/perl6/nqp/tree/jvm_killprocasync -- when you stubbed the op, you planned to return $RT_OBJ. do you remember what you expected the op to return? | |||
09:32Z <lizmat> jnthn: should the BUILDPLANs of nqp match the layout of Perl 6 or not? currently not matching is the underlying cause of RT #132236 | |||
synopsebot | RT#132236 [open]: rt.perl.org/Ticket/Display.html?id=132236 [REGRESSION] Meta object construction | ||
jnthn | sheesh, so message :P | ||
The libuv support for reentrant mutexes is good; we currently implement those ourselves on top of non-reentrant ones | 17:42 | ||
.tell lizmat iirc NQP uses some codes that aren't used in Rakudo, and Rakudo supported them for that reason. I think you asked me about them a while back 'cus you were considering removing them from Mu.BUILDALL. | 17:43 | ||
yoleaux | jnthn: I'll pass your message to lizmat. | ||
jnthn | .tell lizmat If you changed the meanings of the integers and didn't align NQP too then it's possible something coulda broken. | 17:44 | |
yoleaux | jnthn: I'll pass your message to lizmat. | ||
jnthn | .tell bartolin github.com/perl6/nqp/blob/master/s....nqp#L2895 is how it's defined on Moar, so 1 means evaluate to argument 1 (zero-based) | 17:47 | |
yoleaux | jnthn: I'll pass your message to bartolin. | ||
jnthn | .tell lizmat auto-generating BUILD_LEAST_DERIVED would make mixins cheaper; note it's only worth doing for mixin types, but I think you have that information available to you in method compose, or via some .is_mixin method or some such. Can't remember off the top of my head, but I'm sure it's available. So I'd only generate them in that case, not for all classes where it'd be useless | 17:48 | |
yoleaux | jnthn: I'll pass your message to lizmat. | ||
jnthn | Think that's all of 'em, except the channel stress test, which I dunno what'll be :) | 17:49 | |
And I sure don't have the brane left today to look at it :) | |||
timo2 | hello Jonathan how are you doing today? | 17:50 | |
jnthn | timo2: Fine, just a little tired from having family visiting for some days. :) | 17:51 | |
And you? | |||
17:51
committable6 joined
|
|||
jnthn | timo2: Also, congrantsulations :) | 17:52 | |
timo2 | well my wrists have been hurting for a few days now and I have finally decided to use voice recognition to chat | 17:53 | |
thank you | |||
17:53
unicodable6 joined
|
|||
jnthn | Ugh, sore wrists is no fun. :( Hope with some rest and care they'll improve. | 17:54 | |
MasterDuke | timo2: did you see my comment earlier about adding fprintfs in fs_(re)alloc? | ||
timo2 | I'm sorry I did not see that? What did you find | 17:55 | |
whoops | |||
MasterDuke | i added some fprintfs to fixed_size_(re)?alloc in case the bytes are 0 and it dies in the free, but those never print | 17:57 | |
timo2 | I'm wondering if I should buy a new version of Dragon because it says on the website that the newest version is better at understanding accents and noisy environments | ||
and of course I'm also going to looking tools solutions to do some programming with my voice | |||
most of these solutions include some Rube Goldberg kind of set up with virtual machines | 17:58 | ||
right now I literally just have a web browser open inside the virtual machine | |||
also it seems like I have exhausted all of my license activations and I don't even know where the other activated versions are installed | 17:59 | ||
and going from version 12.52 version 15 seems like a decent upgrade | |||
books that understood the two as a number instead of the word | |||
also I accidentally installed the virtual machine on my SSD even though I thought I put it on the external hard drive and my computer ran out of space three times while installing the software | 18:01 | ||
MasterDuke | looks like you need to treat yourself to a bigger ssd and more ram | 18:03 | |
timo2 | well the grant will be paid at the end, but I'll see what I can do | 18:04 | |
while it looks like I would have to pay $300 to get the newest version of Dragon | 18:09 | ||
MasterDuke | ouch | ||
timo2 | alternatively I can get version 13 for not quite as much money | 18:10 | |
MasterDuke | looked on ebay? | ||
timo2 | I don't think that is going to work very well | ||
given how they do the whole license thing and everything | 18:11 | ||
MasterDuke | ah | ||
ugh, hoped the 0 byte free was a precomp thing, deleted all my .precomp folder, but nope, still dies in m-install | 18:15 | ||
timotimo | it's time to run rr on one of those problems | 18:16 | |
MasterDuke | ok, i'm in rr replay | 18:18 | |
SEGV: 0x00007f4b3944e449 in MVM_fixed_size_free (tc=0x556b5cc2ba20, al=0x556b5cc2cf00, bytes=0, to_free=0x0) at src/core/fixedsizealloc.c:280 | 18:19 | ||
timotimo | ok, ow up | ||
you should be able to "print &the_var" to get the addresses where the size and pointer live | 18:20 | ||
it'll give you something like (MVMuint32 *) 0x12345 | |||
you'll want to "watch *((MVMuint32 *) 0x12345)" | 18:21 | ||
and reverse-cont until it trips | |||
MasterDuke | p &(str->body.storage.any) | ||
$3 = (void **) 0x7f4b38421680 | |||
timotimo | ah, yeah, one extra * of course | ||
i've gotta boot my windows quickly and hope there's a dragon installed on there | 18:22 | ||
MasterDuke | Old value = (void *) 0x0 | 18:23 | |
New value = (void *) 0x550000000000 | |||
gist.github.com/MasterDuke17/5ca4c...c515c8ab76 updated with what i've done in rr so far | 18:29 | ||
hm, so if i'm following this, the reason that address is 0 is because the gc zeroed the remaining tospace at collect.c:168 | 18:44 | ||
and then it's being fixed_size_freed | 18:45 | ||
timotimo | my kboard myruoaerr | 18:46 | |
may be running out of battery | |||
MasterDuke | heh | 18:47 | |
timotimo | also, turns out i seem to own dragon 13 professional for some reason | ||
oh, there's the license key and confirmation email | |||
MasterDuke | that's good | 18:48 | |
timotimo | i can't redownload the setup file ... it's been too long since i ordered the thing | 18:49 | |
but i've got the file name now. no wonder i couldn't find it anywhere | |||
MasterDuke | that's ridiculous | ||
timotimo | BEGIN DOWNLOAD EM-K61A-33000-DLM-SR.exe | ||
yeah, i still have it on one of my hard drives | 18:50 | ||
18:55
evalable6 joined
|
|||
timotimo | Securely back up your software online for two (2) years. | 18:56 | |
Now purchasing software online is more convenient than ever. Our Extended Download Service frees you from the time-consuming — but critical — chore of backing up your new software. | |||
isn't that great | |||
surely they have a different installer for every single purchaser | |||
MasterDuke | hm, i keep following that address back in time and it turns into `((MVMP6intBody *)data)->value.i64 = value`, but i guess that's because of the gc moving things around | 19:04 | |
timotimo | oh, the file was actually just a little downloader program | 19:10 | |
not sure what's up with that rr stuff :\ | 19:12 | ||
might be one * too few, too many, who knows? :( | |||
perhaps the type has to be changed | |||
because 0x100 isn't a sensible value here | |||
but even then it should be enough that one byte of the whole pointer gets changed? | 19:15 | ||
are we looking at the pointer, though? or at whatever it points at? | |||
MasterDuke | not sure | 19:18 | |
20:00
timo2timo joined
20:10
releasable6 joined
|
|||
timo2timo | I have now spent some extra time dictating some text with the newer version of Dragon and recognition performance should now be acceptable | 20:35 | |
But first I'm going to make some dinner | |||
Geth | MoarVM: ugexe++ created pull request #719: Use uv_fs_copyfile API |
21:19 | |
23:43
evalable6 joined
|