00:25 travis-ci joined
travis-ci MoarVM build passed. Tobias Leich 'Merge pull request #421 from niner/master 00:25
travis-ci.org/MoarVM/MoarVM/builds/165637599 github.com/MoarVM/MoarVM/compare/5...d33aebbf4c
00:25 travis-ci left 00:46 travis-ci joined
travis-ci MoarVM build passed. Tobias Leich 'use better throw away type for void nativecalls 00:46
travis-ci.org/MoarVM/MoarVM/builds/165639593 github.com/MoarVM/MoarVM/compare/c...dbd6e04adf
00:46 travis-ci left 01:48 ilbot3 joined 05:36 domidumont joined 05:41 domidumont joined
nebuchadnezzar domidumont: hello, I updated the feature/switch-to-libffi branch, if you could review it 06:02
06:13 domidumont joined 06:16 zakharyas joined 06:19 domidumont joined
nine timotimo: happy to be able to help :) 06:21
06:31 geekosaur joined 07:21 brrt joined 11:30 brrt left 11:57 pyrimidine joined
nebuchadnezzar With FROGGS fix for #418, we manage to build MoarVM against libffi but rakudo fails with Floating point exception on armhf: lists.alioth.debian.org/pipermail/...0980.html, any idea? 12:09
geekosaur long division by zero in is_full_collection 12:17
timotimo oh, interesting 12:18
nine I guess we should change src/gc/orchestrate.c:284 to if (uv_resident_set_memory(&rss) < 0 || rss == 0) 12:19
Maybe the Linux kernel just doesn't give you an RSS size on all architectuers 12:20
12:20 MasterDuke_ joined
timotimo i didn't know we inspect the rss there, interesting 12:22
MasterDuke_ since you guys seem to be on a roll with MoarVM fixes, can i interest you in a segfault that's currently causing lots of problems for the whateverable bots and already has some valgrind and ASAN report? rt.perl.org//Public/Bug/Display.html?id=129781 12:25
timotimo hm. i wonder if string_flatten is simply not threadsafe and called by multiple threads on the same string at the same time 12:29
nine This kinda rings a bell 12:32
timotimo i mean ... i don't think string_flatten has any concurrency safety built in
but why would multiple threads be running a regex or something on the same string object at the same time? 12:33
(regex matching is one of the things that causes string flattening)
nine I knew this sounded familiar: irclog.perlgeek.de/perl6/2016-08-26#i_13093882 12:34
MasterDuke_ string_flatten only seems to show up in the ASAN output, but this pattern is in most of the valgrind outputs
==30661== by 0x507B366: uv_mutex_destroy (thread.c:114)
==30661== by 0x4FFEDA1: gc_free (ConcBlockingQueue.c:72) 12:35
==30661== by 0x4FCC0C4: MVM_gc_collect_free_nursery_uncopied (collect.c:580)
timotimo right, that one's also weird
MasterDuke_ ==30661== by 0x4FC8B46: MVM_gc_global_destruction (orchestrate.c:511)
==30661== by 0x505CDF1: MVM_vm_destroy_instance (moar.c:391)
timotimo not sure why we would be trying to destroy the mutex multiple times
MasterDuke_ i get less bad behavior if i explicity use Lock.protect, but it doesn't seem to fix it entirely 12:37
timotimo oh, also if the error happens in MVM_vm_destroy_instance, then we're shutting down already anyway 12:38
12:38 diakopter joined
MasterDuke_ i mention in the bug report that the error goes away if i do an exit, instead of just falling out 12:38
timotimo that's also strange. those should be kind of the same :) 12:39
"to my knowledge" anyway
but that error is probably not going to happen if you don't do --full-cleanup for moarvm, right? 12:40
MasterDuke_ but i think we see it with the bots because we run() perl6 executables
^^^ expansion to my previous comment, not reply to yours 12:41
we don't usually run with --full-cleanup
timotimo OK, fair enough 12:42
dalek arVM: 03352f8 | niner++ | src/gc/orchestrate.c:
Gracefully handle a 0 RSS reported by the Linux kernel

May fix a Floating point exception on armhf in case the reason is that the Linux kernel just reports a 0 for RSS there.		 13:26
arVM: 67dbb75 | lizmat++ | src/gc/orchestrate.c:
Merge pull request #422 from niner/master

Gracefully handle a 0 RSS reported by the Linux kernel
nine nebuchadnezzar: can you please re-test with this version ^^^?
nebuchadnezzar nine: thanks a lot. domidumont could you try the build? 13:58
jnthn nine: Send you a MoarVM commit bit invite :) 14:14
*Sent
nine \o/ 14:17
Wow...I think through valgrinding Inline::Perl5 I've found an actual bug in perl 14:22
timotimo oh, neat!
14:22 hoelzro joined
nine The remaining Inline::Perl5 valgrind error looks a bit like a MoarVM issue to me: gist.github.com/niner/582e3dc1034e...5d00e7a0dd 14:41
jnthn Odd one. 14:46
Maybe reposses wants to memset after gc_free 14:48
nine Sounds a bit like the "re-allocate all the bits inside" the comment promises never happens because we get by with being lazy in that case?
jnthn That may well be the case, yeah
Though I didn't think we were 14:49
(Being lazy about repossessed things)
If the array it's replaced with were to be empty, though, we might never allocate storage again thinking it's not needed 14:50
And thus leave the dangling pointer
It's probably more robust/performant to fix it in serialization.c rather than in the REPR
nine I can give it a try 14:51
jnthn nine++
bbl 14:55
nine Is the storage spec what I'm looking for trying to find the size of the object's body?
timotimo MVMObject has a size member in its header 14:57
it's the header + body size
14:57 FROGGS joined
timotimo i'm just listening to this talk by chandler carruth (works at google, part of the llvm dev team) and one big point he makes is having a "small-size optimized" variant of a vector class (what c++ calls dynamic arrays) is a gigantic win 15:04
that's kind of what we'd get when we have allocation-site specific pre-sizing of arrays
but maybe we also want a little piece of implementation that'd allow us to allocate the dynamic array immediately next to the object as part of the nursery when it initially gets built 15:05
so we don't reach out to malloc for the first allocation
because: hey, maybe a whole lot of lists end up being only ~4 elements big?
like an RGB or RGBA tuple for example, or a 2d or 3d vector
on the other hand, if you use an actual class for those, you'll get "pre-sizing" for free, as well as having all object body data immediately in the nursery 15:06
i wonder if we'd be able to figure out at an allocation site that a list we're allocating needs to be exactly as big as another list we already have at that point 15:10
that'd be kinda neat, but also potentially difficult
dalek arVM: 9a2ab14 | niner++ | src/6model/serialization.c:
Fix "Invalid free()" in empty repossessed arrays

If the promised deserialization never happens or a deserialized array is empty and thus never sees the need to allocate any slots, we could end up free()ing an uninitialized pointer. Clean the object in serialization.c as gc_free() functions usually are not written with the object being re-used in mind.		 15:18
nine Spectest clean and removes the valgrind error :)
timotimo "llvm does everything in the low bits of a pointer" 15:25
jnthn nine: Patch looks reasonable to me 16:12
timotimo jnthn: do we ever want to introduce struct bitfields into moarvm? 16:17
jnthn timotimo: huh, wow, I never knew about those o. 16:27
o.O
timotimo this c++ talk i'm watching is saying they should either be the same speed as manually masking and shifting, or noticably faster
and they are both in C and C++, but i'm not sure how early it came into C
jnthn Yeah, would be curious to know 16:28
Looks from the MSDN like MSVC supports them
timotimo that'd be nice
and they'll likely make the code more readable :)
jnthn So long as we don't use 'em anywhere we care about exact positioning of the bits :) 16:30
timotimo we're not allowed to form references to individual members, but other than that ... :)
i mean, i think we already use a union to figure out if the upper bits of the pointer to mp_int are the flag that it's a smallint ... 16:31
actually, aren't pointers actually 32bit usually?
no, wait
it's int that stays 32bit that was the problem
maybe we're putting that flag in the lower bits 16:32
that'd make more sense
jnthn That's exactly the kind of situation where we'd need to be careful; the ordering and positioning of the bits in the field are compiler/platform dependent. 16:35
16:36 domidumont joined
timotimo hm, OK 16:36
so anything that we make available to rakudo users, for example, that'd be out of the question
16:40 domidumont joined 17:22 nebuchadnezzar joined
domidumont nebuchadnezzar: yes. I'm compiling moar on armhf with nine's patch (thanks !) 17:31
nebuchadnezzar domidumont: I'm building a x32 chroot to test if it continue to segfault 17:32
domidumont: it segfault on x32 :-/ 17:37
domidumont nebuchadnezzar, nine: rakudo now builds on armhf, but some tests are failing. I'll provide more details tomorrow 18:36
nine domidumont: ok, thanks!
18:56 nwc10 joined 18:57 Util joined, japhb joined 19:01 geekosaur joined 19:08 hoelzro joined 19:19 TimToady joined, timotimo joined, ggoebel joined, lizmat joined 19:26 zostay joined 19:33 btyler joined 19:34 diakopter joined, stmuk_ joined, pyrimidine joined 19:37 Dunearhp joined 19:47 cxreg joined, nine joined, mst joined, sivoais joined 19:48 mst joined 19:57 _longines joined, mtj_ joined 20:07 sivoais joined 20:08 konobi joined, avar joined 20:09 camelia joined 20:13 harrow joined, jnthn joined 20:18 sivoais joined 20:21 ilmari_ joined, BinGOs_ joined, JimmyZ_ joined, psch_ joined, moritz_ joined 20:22 arnsholt joined, [Coke] joined 20:27 BinGOs joined 20:38 _longines joined, nine joined, pyrimidine joined 20:39 mtj_ joined, btyler joined, ggoebel joined, TimToady joined, nwc10 joined, avar joined, konobi_ joined, cxreg joined, Dunearhp joined, lizmat joined 20:40 jnthn joined, camelia joined, mst joined, stmuk_ joined, japhb joined, geekosaur joined 20:47 sivoais joined 22:09 geekosaur joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!