🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth tap-harness6: 1ececb26f2 | (Leon Timmermans)++ | 2 files
Fix Supplier name in Output::Supplier
 00:00
tap-harness6: 6fb155162e | (Leon Timmermans)++ | 3 files
0.3.1
patrickb japhb: I have just seen the latest RSC minutes and the question about the state of the CI bot grant. The grant hasn't stalled. It is progressing slower than anticipated though. Latest report is here: news.perlfoundation.org/post/2021-...ant-update 08:17
tellable6 2021-12-19T14:46:51Z #raku <SmokeMachine> patrickb sorry I haven’t seen your issue before, but I’ve just answered: github.com/FCO/Red/issues/539#issu...-997403720
2021-12-19T14:56:28Z #raku <SmokeMachine> patrickb also this one: github.com/FCO/Red/issues/538#issu...-997405831
patrickb Am I assuming correctly, that we have no analytics whatsoever on rakudo.org and raku.org at the moment? 08:42
If yes, what do people think about adding goatcounter.com to both of them? 08:43
nine patrickb: oh, that report's a joy to read :) Thanks for doing the right thing (TM) about bugs you encounter. That may not be what the grant is actually about, but it's a great service to our users. 08:47
OTOH what's the point of CI if not to catch bugs? :D So this may very well be on topic
MasterDuke patrickb: does raku have a large userbase among goats? i would prefer we count visits by people 08:52
patrickb :-P But how could you know whether there are people or goats sitting in front of all those keyboards? I remain with goatcounter being just as legitimate a name as peoplecounter. 08:54
MasterDuke en.wikipedia.org/wiki/On_the_Inter...et_dog.jpg 08:56
nine MasterDuke: honestly, if goats find our software useful, I'm ok with that. 08:57
patrickb: I'm curious about that NativeCall issue... 09:01
MasterDuke nine: i'll have to look for a means to use raku next time i play goat simulator 09:03
nine patrickb: of course I cannot reproduce it locally... Can you still? 09:06
patrickb nine: I can't. 09:16
nine Not in the full app either? 09:17
patrickb This is a bit frustrating, as that golf is about 1.5 hours worth of golfing...
I'll try...
nine: I got a repo with the full app. 09:37
nine darn
patrickb Took 12 runs
nine: Are you interested in an explanation on how to set this up? Alternatively, would you recommend me to invest time in golfing this down once more? 09:42
nine I fear a golf would be much more useful, since it's hard to reproduce, will want some rr, etc. 09:45
patrickb OK 09:46
nine: I might still have the RR record lying around. Is that of any help? 10:03
nine Only if you have exactly the same MoarVM + rakudo + OpenSSL installation to go with it. Unfortunately rr recordings do not include the program code and if the latter just differs slightly from the time of the recording rr will usually break 10:36
patrickb I just tried `rr replay` and it does run through. 10:39
nine Okidoki....so the first challenge would be to set a break point at the place where we notice things to go wrong 10:42
patrickb there is a print "Unable to read key" 10:43
can I break on stdout/err?
Uhm... there is also the warning: "warning: .dynamic section for "//home/patrick/rrepos/install/lib/libmoar.so" is not at the expected address (wrong library or version mismatch?)" 10:47
Will that mess things up?
wait 10:48
nine potentially yes
I'm not aware of a way to break on output
patrickb ugh
nine How is that printed?
patrickb the warning or the Unable to read key?
nine Unable to read key 10:49
patrickb die "Unable to read key" unless defined($rsa);
nine Maybe a break on MVM_exception_throw_adhoc will trigger
MasterDuke MVM_exception_die 10:50
patrickb ok. Lots of "unrecorded signal" warnings. I guess this won't do.
I'll try to get a live repro again. I'll report back if / once I succeed. 10:51
nine Well, if you've got to reproduce again anyway, you can at least make debugging easier, e.g. by putting something like nqp::sin_n(1e0) into a place where you want to break. Then place the break point on the sin_n implementation in src/core/interp.c 10:52
patrickb ok
patrickb nine: I can repro with a rakudo/MoarVM master as of 2021-11-27 and have it captured in rr, have put in a sin_n and have rr break on that sin_n right before the call to OpenSSL::PEM::PEM_read_bio_RSAPrivateKey (the call that fails to do what it should). 12:09
nine nice! 12:11
Btw. why the old master? 12:12
patrickb That's the build that was still lying around 12:16
I did a build with latest master and it didn't fail. I suspect it's not really fixed by latest master though as there are no changes in MoarVM since then that look like they could have fixed it and the bug is depending on soft factors (as can be seen by not failing any more on 2021.09). 12:17
So I think it's still worth debugging on this older build even though there is a chance it turns out to have already been fixed. 12:18
nine Ok, so PEM_read_bio_RSAPrivateKey fails. What's the failure mode? Missing return value? 12:25
patrickb yes
nine What does the bytecode of the frame calling PEM_read_bio_RSAPrivateKey look like? 12:26
patrickb rr somehow still throws exceptions when stepping through the code. Should I try fixing rr or is there a chance of doing this with gdb?
How do I find out?
nine call MVM_dump_bytecode(tc) 12:26
patrickb paste.sr.ht/~patrickb/2935953d1e8a...a89c3afbdf 12:29
paste.sr.ht/~patrickb/47d0186b2afd...3a31763the corresponding raku code: 12:31
nine So this should be the failing call: 00081 dispatch_o loc_3_obj, 'lang-call', Callsite_8, loc_5_obj, loc_1_obj, loc_9_obj, loc_8_obj, loc_3_obj 12:34
Can you advance to just after this call and then have a look at what's in tc->cur_frame->work[3].o?
You can probably just set a break point at PEM_read_bio_RSAPrivateKey (should have thought of this earlier...) and then finish frames until you are back in src/core/interp.c
patrickb is trying 12:35
nine I find it odd that this is clearly unspeshed code while your bugreport says that with spesh disabled the bug bug disappears. 12:40
bartolin Hmm, reading this I can't help to think of github.com/sergot/openssl/issues/82 and github.com/sergot/openssl/issues/87 which I tried to debug last year. The installation of OpenSSL failed (but not reliably) -- seemingly in the same place. My guess back then was that precomplication was somehow involved with these failures. 12:43
(hopefully this doesn't point you in the wrong direction and distract you from the real problem) 12:44
nine Looks like different issues 12:47
patrickb back in interp.c I am now looking at OP(return_o)
Have I mis-stepped? 12:48
nine You can always dump bytecode to see where you are. There's also call MVM_dump_backtrace(tc) 12:49
You could be in the dispatch program 12:50
patrickb that small arrow points to the currently executing op?
That's pointing at 00082 -> decont loc_3_obj, loc_3_obj 12:51
nine Sort of, mostly 12:54
patrickb stepping over the return_o I am now actually in the OP(decont) 12:55
nine on a good day
The one that's following the dispatch_o? Then yes, the return was in the dispatch program. Now tc->cur_frame->work[3].o is of interest
patrickb {header = {sc_forward_u = {forwarder = 0x550000001e, sc = {sc_idx = 30, idx = 85}, st = 0x550000001e}, owner = 1, flags1 = 1 '\001', flags2 = 2 '\002', size = 24}, st = 0x41a72f8} 12:56
nine What's in st?
patrickb {header = {sc_forward_u = {forwarder = 0x100000001e, sc = {sc_idx = 30, idx = 16}, st = 0x100000001e}, owner = 1, flags1 = 2 '\002', flags2 = 2 '\002', size = 168}, REPR = 0x7ffff7e41ec0 <CPointer_this_repr>, REPR_data = 0x0, size = 32, type_check_cache_length = 3, mode_flags = 0, type_check_cache = 0x34be6d0, type_cache_id = 849920, container_spec = 0x0, container_data = 0x0, boolification_spec = 0x34be6f0, hll_owner = 0x4dd190, hll_ro
what does st stand for?
nine STable
The object's flags1 is 1, which is MVM_CF_TYPE_OBJECT, so you got a NULL pointer there 12:58
Did PEM_read_bio_RSAPrivateKey really return NULL?
patrickb now I regret not having rr working...
nine s/got a NULL/got a CPointer type object which stands for NULL/
Oh, that's in gdb? Bummer :(
patrickb It's reproducible 12:59
but yes, somehow rr fails as soon as I start stepping
nine And with a break point on PEM_read_bio_RSAPrivateKey you should find the right spot quickly
patrickb true, as I previously did
nine Locally I use an rr built from source, so I always get the latest bug fixes
Still sometimes happens that a replay crashes but works when tried again. I guess rr does some really deep magic 13:00
patrickb AFK for a bit. Back in a few minutes...
Geth rakudo: 186bd0b026 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Rename Any.infer to Any.are

By popular request, also make sure that anything that has an
  .iterator method will work, not just Lists		 14:45
patrickb nine: I think I found the error. It's a bug in our OpenSSL wrapper. The `BIO_new_mem_buf` creates a BIO struct and copies the Buf pointer passed as the first argument into it. My golf (just as the OpenSSL wrapper) passes `$key.encode` and thus Rakudo subsequently frees that Buf and leaves the BIO with a broken buf. 16:47
nine: According to the OpenSSL docs BIO_new_mem_buf does not take ownership of that buf. So the solution can't be to put `explicitly-manage()` around the arg. 16:49
Is there a way to guarantee that Rakudo will not GC-more a Buf around? I.e. I could just keep the Buf alive in Rakudo land by holding it in a variable. But I need to guarantee that that pointer that escaped into C land stays valid. Can I do that somehow? 16:51
lizmat if the Buf is big enough, it doesn't get created in the nursery? 16:53
nine patrickb: for that pointer to stay valid, the Buf object must be kept alive. And it must stay the same size (otherwise the VMArray may realloc the buffer).
lizmat ok, scratch my idea :-) 16:54
nine The buffer itself that's pointed at is malloced, so no worry about that.
patrickb I think my understanding of moar is flawed. Doesn't the GC shuffle about everything around as it likes? Are Bufs special? 16:57
nine Raku's Bufs (and Blobs) are REPR VMArray. VMArrays are GC-able 6model objects. They consist of the common header, and a body: github.com/MoarVM/MoarVM/blob/mast...rray.h#L39 17:01
The body then contains some information about the size of the array and the actual pointer to the memory holding the elements: github.com/MoarVM/MoarVM/blob/mast...Array.h#L8
This slots array is plain malloced memory and the GC doesn't care about this. The GC only cares about the object holding that pointer. C code just gets passed the pointer to the slots array 17:02
The slots array gets freed when the VMArray objects gets freed. This is by way of the GC calling the object's gc_free method which takes care of such things: github.com/MoarVM/MoarVM/blob/mast...ray.c#L112 17:04
patrickb I think I understand.
Does that general principle apply to all things one can pass to native functions? 17:05
patrickb starts to suspect this is one of the things all that REPR stuff is about. 17:06
nine Yes. We never actually pass a pointer to an MVMObject to C code. It depends on the REPR what the C code actually sees. Strings for example go through MVM_string_utf8_encode_C_string or the like. For integers, we pass whatever MVM_repr_get_int returns on that object. 17:10
patrickb nine: Nice. Then I think I know how to fix this bug. Thank you for explaining so much to me! 17:17
nine You're welcome :) 17:50
gfldex m: (^∞).hyper.map({ last }); 20:03
camelia (signal XCPU)
gfldex Should that terminate properly? 20:04
lizmat interesting :-)
ugexe im imagine last short-circuits as soon as it can, but that might mean the other units of work need to get finished (but that no more would be created) 20:06
and of course all the other work is also infinite 20:07
well no, nevermind thats not right
gfldex usecase: gist.github.com/7b2f312317dc7a598c...367a05f3fd 20:08
Should I Rakudobug?
ugexe it looks like it works for `for` though 20:10
gfldex m: my atomicint $bail = 0; (^∞).hyper.map({ say $bail⚛++; last if $bail > 3; }); 21:02
camelia (signal XCPU)0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49…
gfldex The map seems to respect last, but the iterator that spawns batches doesn't know. 21:03
We are not really good at stopping threads in general. 21:04
filed as RT#4712 21:07
Geth rakudo/rakudo-4711: 28b512380b | (Vadim Belman)++ | src/Perl6/World.nqp
Make add_constant lookup setting symbols only

The compiler is only uses this method with core types. Limiting lookups to setting only prevents LTA errors in user code.
Fixes #4711		 21:23
rakudo: vrurg++ created pull request #4713:
Make add_constant lookup setting symbols only
Geth rakudo: 28b512380b | (Vadim Belman)++ | src/Perl6/World.nqp
Make add_constant lookup setting symbols only

The compiler is only uses this method with core types. Limiting lookups to setting only prevents LTA errors in user code.
Fixes #4711		 22:01
rakudo: 94b9d497ef | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/World.nqp
Merge pull request #4713 from rakudo/rakudo-4711

Make add_constant lookup setting symbols only
japhb (backlogging) Ah, thank you patrickb for the clarity on the CI bot grant. Glad to know it's not stalled. :-) 22:31

Powered by Cro and the Raku® Programming Language.

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

Thank you!