00:09 pyrimidine joined 01:04 geekosaur joined 01:25 pyrimidine joined 02:05 pyrimidine joined 02:07 stmuk joined 02:25 stmuk joined 02:48 ilbot3 joined 03:14 pyrimidine joined
IOninja .tell dogbert17 I'm told you like hunting SEGVs: irclog.perlgeek.de/perl6/2017-02-24#i_14155509 03:24
yoleaux2 IOninja: I'll pass your message to dogbert17.
03:37 MasterDuke_ joined 06:16 pyrimidine joined 06:25 ggoebel joined 07:52 stmuk joined
nwc10 good *, #moarvm 07:55
08:13 pyrimidine joined 08:56 zakharyas joined 09:14 pyrimidine joined
samcv good * :) 09:17
jnthn morning o/ 10:02
yoleaux2 23 Feb 2017 21:08Z <IOninja> jnthn: Num.Rat coerser takes optional epsilon, Int.Rat and Rat.Rat take an optional arg they ignore, and Complex.Rat and Str.Rat don't take any args. Does it make more sense to make all .Rats take an optional arg and ignore it in cases or just have it for types that can make use of it? I'm leaning towards the latter, and removing dummy params
10:16 pyrimidine joined
dogbert11 silent around here 10:18
jnthn My brain cycles are tied up with a fun but somewhat tricky yak shave at work... :) 10:21
dogbert11 oh no :) if you get tired of it I have a juicy IOninja SEGV that might be interesting 10:25
the SEGV gist is here: gist.github.com/dogbert17/9aadb12c...dab001eb1b 10:35
updated the gist, it now contains gdb, valgrind and ASAN output 11:09
timotimo dogbert11: do you still have a gdb running where that happened? 11:13
jnthn Oh noes, seems that we don't support function pointers in CStructs yet? 11:23
arnsholt Hmm 11:24
jnthn I need to pass a struct of callbacks, fwiw.
arnsholt I guess we might only support passing them to functions?
jnthn Yeah, that's what it looks like
We also support casting returned function pointers into Perl 6 callables 11:25
It's funny, if C had an identity function I could easily call then I could just pass my code, and get back a pointer that I can stick into the struct :P 11:26
I can't think of anything in standard library that I can abuse as an identity function though :P 11:27
timotimo yeah 11:29
pretty annoying
can totally put one into moarvm :)
that'll make sure it's available "everywhere"
(except on jvm)
arnsholt Or we could, y'know, fix NativeCall =p 11:32
jnthn Or that :) 11:33
arnsholt I've been wanting to draft a revised NativeCall API, incidentally
jnthn *nod*
Something we can better JIT would be good :)
arnsholt And something more coherent
jnthn Aye
arnsholt It's sprouted a few too many hacks, IMO
jnthn That also 11:35
jnthn wonders what the most expedient thing he can do Right Now is 11:36
(I can always switch to a better thing later)
arnsholt Horrrible, horrible hack, but you could make the struct of OpaquePointer, and get pointers to the functions with dlsym and dlopen(NULL)? 11:37
Except you're wanting to populate it with callbacks to *Perl 6* functions >.<
What about memcpy? 11:38
jnthn Right
I pondered that but...memcpy expects to receive a pointer
A really horrid back is printf("%P", ...) :P 11:39
*hack
arnsholt Right, so you'd have to pass a CArray[OpaquePointer]
jnthn Yeah, but what I'd be trying to pass is a Perl 6 function 11:40
Which I want to get the callbackized pointer to
The only place we support callback *generation* today is when we pass them as an argument 11:41
arnsholt Won't "my CArray[OpaquePointer] $arr; $arr[0] = OpaquePointer; memcpy($arr, &cb, 8); $arr[0]" work?
Oh, not 11:42
You're right, yeah
Bah!
This was really annoying!
jnthn: signal(2) 11:44
}:)
It'll return the previous signal handler, so set the signal handler to be your callback, then set it back to the original value and save the final return value in your struct 11:45
jnthn ouch :) 11:46
But yeah, nice one :)
dogbert11 timotimo: yes
what would you like me to do? 11:49
timotimo can we get a bt full?
dogbert11 coming up 11:50
timotimo dont know how to print all locals in a frame youre in
dogbert11 gist updated, refresh 11:51
jnthn Hm, there may be an alterantive API that lets me side-step the whole thing 12:00
timotimo how in the heck does desc become 0x1 12:12
wrong kind of object perhaps?
but it has to match the rakudo container spec 12:13
can you print the STABLE(check)?
well, may have to STABLE(check)[0]
i'm grabbing the code myself now,too 12:17
12:17 pyrimidine joined
timotimo HTML-Entity is failing its tests, did you see that, too? 12:20
huh. it installed HTTP::Tinyish, then it tries to install & test HTTP::Server::Tiny and it fails to find HTTP::Tinyish? 12:23
i wonder what causes the descriptor to become damaged like that 12:32
dogbert11 timotimo had sneaked off for lunch :) 12:37
in order to run mapper.pl you only need JSON::Tiny 12:38
(gdb) p STABLE(check)[0] 12:39
$2 = {header = {sc_forward_u = {forwarder = 0x15a0017, sc = {sc_idx = 23, idx = 346}, sci = 0x15a0017, st = 0x15a0017}, owner = 1, flags = 18, size = 120}, REPR = 0xb68a4440 <this_repr>,
REPR_data = 0xb5220c00, size = 32, type_check_cache_length = 3, mode_flags = 4, type_check_cache = 0xabb9c0d0, method_cache = 0xa82dac60, type_cache_id = 127232,
container_spec = 0xb4f1bea0 <rakudo_scalar_spec>, container_data = 0x0, boolification_spec = 0xabb9c0b0, hll_owner = 0xb1405b40, hll_role = 0, invoke = 0xb61033a0 <MVM_6model_invoke_default>,
invocation_spec = 0xb462b010, WHAT = 0xb3e3edd0, WHO = 0xaaa193c0, HOW = 0xabd2d6a0, paramet = {ric = {parameterizer = 0x0, lookup = 0x0}, erized = {parametric_type = 0x0, parameters = 0x0}},
HOW_sc = 0xa5654220, HOW_idx = 12624, method_cache_offset = 141235, method_cache_sc = 0x0, debug_name = 0xabb9c070 "Scalar", being_repossessed = 0 '\000'}
dogbert11 oops that was a bit on the spammy side
timotimo i got it into gdb locally, too 12:58
dogbert11 cool, any ideas? 13:00
timotimo i'm not sure where exactly it is in the bytecode
doesn't help that our backtraces seem to be pretty bad near the top all the damn time :)
it'd be nice if the code was golfed a bit more ... 13:12
13:19 pyrimidine joined
arnsholt Awww. MoarVM doesn't work in Linux-on-Windows because of executable stack 13:23
jnthn There's an issue about that; apparently we get it from dyncall, which doese it by accident, so it was being fixed there 13:24
dogbert11 timotimo: we could ask the ninja :) 13:27
IOninja ? 13:28
ask what... and which ninja
I'm surprised HTTP::Tinyish is used anywhere in that codebase :S 13:29
oh, same author, now less surpised. 13:30
You don't need it for the script with the SEGV in it tho 13:31
Only JSON::Tiny
And HEAD doesn't segv (I needed to work around it), it's on that commit only... 13:32
Umm, I think I forgot to commit all the latest changes tho (not important)
zef install JSON::Tiny; cd $(mktemp -d); git clone github.com/perl6/routine-map .; git checkout ee7fb894bc47f8eed; perl6 mapper.p6 13:33
dogbert11 IOninja: we're trying to golf it a bit
IOninja And if you change `eager` to `@ =` on this line, the segv goes away: github.com/perl6/routine-map/blob/...per.p6#L53 13:34
dogbert11 and we thought you might be able to help :)
IOninja OK. Yeah, lemme golf it down
m: CORE::.keys.grep(* ne 'IterationEnd').map({CORE::{$_}}).grep({ !.DEFINITE and try .can('say') }).unique.grep({42}) 13:40
camelia (signal SEGV)
IOninja ^ that's what I got so far 13:41
s: CORE::.keys.grep(* ne "IterationEnd").map({CORE::{$_}}).grep({ !.DEFINITE and try .can("say") }), 'unique', \()
... wonder if it's me lagging or the bots :/ 13:42
oh, no SourceBaby here
my spidey senses tell me this is something to do with trying to .unique an Iterable that has all sorts of weird crap in it 13:44
And my spidey senses pay off: 13:47
m: (Scalar).unique
camelia (signal SEGV)
IOninja dogbert11: how's that for golf :P 13:48
dogbert11 IOninja: I guess it's called hole in one :) 13:52
can we use some cool bot to see if this problem was introduced recently 13:57
bisect: (Scalar).unique
meh 13:58
IOninja dogbert11: some time in 2015.09: gist.github.com/Whateverable/76982...a953f9041b 13:59
dogbert11 an oldie 14:00
IOninja I'm golfin' it more
dogbert11 is that even possible
IOninja Sure, unique is just code 14:01
m: return Scalar
camelia (signal SEGV)
IOninja Still golfin'! 14:09
m: use nqp; nqp::p6recont_ro(Scalar)
camelia (signal SEGV)
IOninja well, that's as far as I can take it. The rest is all C code and I don't know C. 14:11
dogbert11 IOninja: I think that will do nicely 14:13
dogbert11 don't understand what's going on either, will have to learn from the pros 14:20
IOninja first appeared in 2014.05 release 14:21
no segv in 2014.04, but I dunno if that's 'cause this op didn't exist then maybe
Geth MoarVM: niner++ created pull request #541:
Yet another attempt at silencing the pthread_yield warnings		 14:33
IOninja #0 0x00007ffff5d67701 in p6recont_ro () from ./dynext/libperl6_ops_moar.so 14:36
No symbol table info available.
how do I get the symbol table info agvailable?
dogbert11 are you running gdb? 14:40
IOninja I guess. ./perl6-gdb-m 14:41
dogbert11 if so, in nqp/MoarVM do this 'perl Configure.pl --debug --prefix=/home/dogbert/repos/rakudo/install/' followed by 'make install'. Note, change the prefix accordingly 14:42
I doubt that your install dir is the same as mine :)
IOninja Yeah, I did, but this stuff's not in MoarVM this is C code in rakudo
dogbert11 hmm, that's what I do 14:44
which gives me:
#0 0xb4a032ce in MVM_is_null /home/dogbert/repos/rakudo/install/include/moar/6model/reprs/MVMNull.h:11
#1 0xb4a032ce in p6recont_ro /home/dogbert/repos/rakudo/src/vm/moar/ops/perl6_ops.c:268
IOninja wonder if rakudo needs to be re-parsed and recompiled after just a change in .c code 14:48
takes ages
in src/vm/moar/ops/perl6_ops.c
dogbert11 don't think so, when I make changes in the MoarVM code I do what I described above. I only rebuild rakudo when I want the latest changes from upstream 14:50
on the other hand, that code isn't in MoarVM 14:51
dogbert11 shuts up
MasterDuke_ dogbert11: have you tried running cppcheck (i think that's what you used recently on Moar) on the rakudo c code? 14:56
dogbert11 MasterDuke_: yes, but the version I have at $work (1.61) choked :( 14:58
perhaps you have a newer version ...
MasterDuke_ i just installed 1.77 here at home
how did you run it? i've never used it before 14:59
dogbert11 cppcheck <path> 2> err.txt 15:00
if you point to a directory the program will do a recursive check 15:01
MasterDuke_ no errors in ./src/vm/moar/ops/container.c or ./src/vm/moar/ops/perl6_ops.c 15:02
dogbert11 try with --enable=warnings 15:06
MasterDuke_ still nothing 15:08
dogbert11 well, perhaps the code is clean :) try it in MoarVM instead 15:09
MasterDuke_ [core/exceptions.c:767]: (error) Uninitialized struct member: lh.handler_out_of_dynamic_scope 15:11
[core/hll.c:275]: (error) Uninitialized variable: result
[platform/inttypes.h:6]: (error) #include nested too deeply
same things you found? 15:12
dogbert11 yes, but I haven't checked if they are legit or false positives. it's possible that Moritz have done that though 15:13
the hll.c one looks like a false positive to me 15:14
MasterDuke_ the one in core/hll looks bogus
dogbert11 agreed
IOninja Well, using sheer brute force and copious printfs(), I golfed the SEGV further down to `((Rakudo_ContainerDescriptor *)desc)->rw`.... umm... method call? struct field look up?... in p6recont_ro
More exactly `if ( ((Rakudo_ContainerDescriptor *)desc)->rw ) { printf("here2.1.3\n"); }` line segfaults 15:15
dogbert11 i.e. line 268 15:17
jnthn Does it do an IS_CONCRETE(desc) somewhere before the dereference? 15:18
MasterDuke_ nope, just `!MVM_is_null(tc, desc)` 15:19
moritz dogbert11: I couldn't substantiate the claim about lh.handler_out_of_dynamic_scope
IOninja jnthn: !MVM_is_null(tc, desc)
moritz but I couldn't dismiss it entirely either
IOninja oh, hm
MasterDuke_ building right now with an added IS_CONCRETE(desc) 15:20
IOninja My `if ( !MVM_is_null(tc, desc) ) { printf("here2.1.1\n"); }` does print so that means ((Rakudo_ContainerDescriptor *)desc)->rw never actually runs in that code
Or.. not supposed to
jnthn Worth trying adding the IS_CONCRETE
jnthn is tied up writing an async binding to a C library, so not following too closely here :) 15:21
IOninja Oh wait, I misread the conditional, yeah tis supposed to run :)
Here's my diff and output: gist.github.com/zoffixznet/dba1581...c3b51d96e8
MasterDuke_ changing `if (!MVM_is_null(tc, desc) && ((Rakudo_ContainerDescriptor *)desc)->rw) {` to `if (!MVM_is_null(tc, desc) && IS_CONCRETE(desc) && ((Rakudo_ContainerDescriptor *)desc)->rw) {` still segfaults
IOninja MasterDuke_: how did you build it so fast?
MasterDuke_ it takes about 100s to build 15:22
IOninja oh ok, same here...
15:22 ggoebel joined
MasterDuke_ fwiw, here's a gist of the valgrind output, gist.github.com/MasterDuke17/42a43...4e236d23d4 15:24
though it used to say invalid read of size 8 before i added that IS_CONCRETE(desc)
IOninja how to run valgrind? 15:30
dogbert11 there is a perl6-valgrind-m you can run
IOninja Ah, thanks
dogbert11 it can be a tad slow sometimes (understatement) 15:56
16:10 pyrimidine joined
IOninja filed proper ticket for `unique Scalar` SEGV: rt.perl.org/Ticket/Display.html?id...xn-1450111 16:21
MasterDuke_ ah, i got it to not segfault. if it just does nothing is that ok? 16:31
spectests clean 16:36
i'll create a PR so someone can take a look at it 16:37
dogbert17 MasterDuke_++ 17:27
yoleaux2 03:24Z <IOninja> dogbert17: I'm told you like hunting SEGVs: irclog.perlgeek.de/perl6/2017-02-24#i_14155509
17:32 pyrimidine joined 18:07 pyrimidine joined
timotimo wow, i could kick myself for not having the concreteness idea there 18:09
dogbert17 now you have a concrete example :)
lizmat jnthn: re nqp::list vs IterationBuffer 18:14
MasterDuke i wondered about that `check` variable early on, but tried adding `check && STABLE(check) &&` where i ended up adding `IS_CONCRETE(check) &&` and it made no difference
lizmat jnthn: historically, before GLR, $!reified was always an nqp::list
jnthn: now it can basically either be an nqp::list or an IterationBuffer 18:15
timotimo IterationBuffer is only a minimal step up from nqp::list
but it should probably be unified
lizmat jnthn: do you see any reasons to not make it an IterationBuffer always ?
timotimo: thing is, if you pass an nqp::list around as a parameter, it gets upgraded to a List 18:16
an IterationBuffer does noet
timotimo that seems annoying :)
lizmat *not
18:16 zakharyas joined
lizmat well, doing a .sort atm creates at least 2 List objects that get discarded almost immediately 18:16
which creates nursery pressure
unnecessary nursery pressure :-) 18:17
timotimo they get created because an nqp::list goes through nqp::hllize?
(that would be what turns an nqp::list into a List)
lizmat yeah, think so
timotimo OK, sounds like a good spot for an IterationBuffer
lizmat m: use nqp; dd nqp::list'
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> use nqp; dd nqp::listā'
expecting any of:
infix
infix stopper
postfix
statement end
statement modiā€¦
lizmat m: use nqp; dd nqp::list 18:18
camelia ()
lizmat m: use nqp; dd nqp::create(IterationBuffer)
camelia ()
lizmat wow ?
ah, that'd be the IterationBuffer.perl I added some weeks ago :-)
timotimo :D
lizmat m: use nqp; dd nqp::create(IterationBuffer).WHAT 18:20
camelia IterationBuffer
lizmat m: use nqp; dd nqp::list.WHAT
camelia ()
lizmat m: use nqp; dd (nqp::list).WHAT
camelia ()
lizmat hmmm
m: use nqp; dd (nqp::list).^name
camelia "BOOTArray"
timotimo so that's not enough to hllize it
m: use nqp; dd nqp::what(nqp::list)
camelia ()
timotimo m: use nqp; dd nqp::hllize(nqp::list).^name
camelia "List"
lizmat m: use nqp; say nqp::list.perl
camelia Cannot find method 'perl': no method cache and no .^find_method
in block <unit> at <tmp> line 1
lizmat m: use nqp; sub a(\a) { dd a.WHAT }; a nqp::list 18:21
camelia List
dogbert17 timotimo: do you understand this code? github.com/MoarVM/MoarVM/blob/mast...call.c#L13
there are two 'strcmp(cname, "stdcall")' in there, looks a bit strange 18:22
timotimo yeah, that looks kind of wrong 18:25
clearly one is meant to give you the 64bit one and another the 32bit one 18:26
dogbert17 perhaps it shouldn't be 'stdcall' in one of the cases?
timotimo i have no clue of different call conventions 18:27
i'm not sure you can even properly call into 32bit code from a 64bit program
dogbert17 me neither
timotimo don't you have to switch the processor into 32bit mode for that to work?
dogbert17 no clue 18:28
perhaps froggs knows 18:29
timotimo having a headache doesn't help things 18:30
dogbert17 ouch
18:36 pyrimidine joined
jnthn lizmat: IterationBuffer is just as efficient (memory, time) as nqp::list 18:36
lizmat jnthn: yes, I know
jnthn lizmat: It's just a type based upon the same REPR
lizmat but IterationBuffer doesn't get HLLized
jnthn Right
lizmat and nqp::list does
which makes for a lot of List object creation all of the time in the setting 18:37
jnthn I added IterationBuffer so we could have something quite primitive and pass it around
lizmat just because of passing along an nqp::list that could be an IterationBuffer
jnthn In Perl 6 space
In the original GLR exploration I did, $!reified was always an IterationBuffer 18:38
lizmat but that broke a lot, I guess :-)
jnthn Not really
lizmat so what made you decide not to do that ? 18:39
jnthn Well, it wasn't really a concious decision not to, so much as that in a handful of cases (like nqp::vmargarray or whatever it's called) you just ended up with an nqp::list
It doesn't break anything
I suspect nowadays, because you can in many cases (like, when no $!todo) get away with nqp::list and IterationBuffer, we've got a profileration of nqp::list in there that could be IterationBuffer instead. 18:40
I'm find with using IterationBuffer more widely for $!reified, especially if it makes other things easier :) 18:41
*fine
In fact, I'd prefer it that way :)
lizmat ok, will look at it then :-)
jnthn Note that IterationBuffer is still a semi-internals-y type
It's there primarily so people writing custom Iterators could receive a lightweight, Perl 6 type to push things into 18:42
It's fine for us to use it in internals where we wish
Just be careful we don't "leak" there out of places that should return List 18:43
s/there/them/ 18:44
(e.g. where we were previously relying on hllize to make a List)
lizmat jnthn: yeah, gotcha :-) 18:47
jnthn github.com/jnthn/p6-ssh-libssh # what ate my brane cycles today :) 18:51
IOninja cool :)
jnthn For anyone curious what my NativeCall questions were about earlier :)
Quite nice that we can write basic async bindings to native libraries in Perl 6 without needing any intermediate C stuff 18:53
Was really hard to find examples of doing libssh non-blocking too 18:54
And the docs are...interesting :-)
Will stick it on modules.perl6.org once I get it far along enough that it's useful for the $dayjob project I need it for. 18:57
Then will see if I can find free time tuits to fill out the bits that project doesn't need. :-)
(I don't need the server parts at all, for example) 18:58
(But it might be fun to write the binding for that)
timotimo did you end up getting something to put function pointers into structs? 18:59
jnthn No
I found a way to not have to do that
I only need to juggle a small number of connections for what I'm doing; the function pointer/struct thing was needed to make it scale better up to dozens/hundreds 19:00
So it just wasn't worth the yak shave
Though I did along the way find a NativeCall bug 19:02
Got a local MoarVM patch for that but want to write some tests for the NativeCall test suite first
19:12 lizmat joined
[Coke] jnthn: (github.com/jnthn/p6-ssh-libssh) don't forget a LICENSE. 19:31
(having just gone through a license hunt for $dayjob) 19:32
19:35 pyrimidine joined 19:57 MasterDuke joined
jnthn [Coke]: I should probably do a check on all my modules for that, since I're likely missed it in a few 20:13
timotimo use perl6-all-modules for that! :D 20:14
[Coke] Danke.
moritz whenever somebody mentions perl6-all-modules, I have the sudden urge to update it again 20:16
I guess I should really create a cron job for that
timotimo %) 20:17
probably
moritz I'm just uncomfortable leaving my SSH key unprotected for a cron job
guess I should investigate if I can create an RW ssh key for that one repo
timotimo yeah, should be able to 20:18
20:26 ggoebel joined 21:17 pyrimidine joined 22:02 sivoais joined 22:12 sivoais 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!