🦋 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.
00:02 reportable6 left 00:05 reportable6 joined 00:40 patrickb left, patrickb joined 01:51 evalable6 joined 02:08 patrickb left 03:55 releasable6 left, evalable6 left, linkable6 left 03:56 evalable6 joined 04:35 squashable6 left 04:56 linkable6 joined 04:58 releasable6 joined 05:48 frost joined 05:49 frost left 05:55 frost joined 06:03 reportable6 left 06:04 reportable6 joined 06:56 frost left
Geth URI: 2e62d0f117 | (Jonathan Stowe)++ | 3 files
Fix warning in URI::Path

This was noticed in the tests for Webservice::AWS::Auth::V4 when it was passing an invalid URI.		 07:49
08:33 evalable6 left, linkable6 left 08:34 linkable6 joined 09:26 squashable6 joined 09:33 evalable6 joined
[Tux] Rakudo v2021.10-124-g6fce35ba8 (v6.d) on MoarVM 2021.10-111-gbd83921de
csv-ip5xs0.849 - 0.861
csv-ip5xs-205.261 - 5.650
csv-parser4.086 - 4.114
csv-test-xs-200.421 - 0.421
test7.019 - 7.036
test-t1.642 - 1.669
test-t --race0.958 - 0.982
test-t-2024.391 - 25.709
test-t-20 --race7.270 - 7.563
 09:36
10:27 Xliff joined 12:02 reportable6 left 12:05 reportable6 joined 14:46 patrickb joined 14:48 Colt left
Xliff *sigh* 15:32
Had to abort p6 timings for the second week in a row: 15:33
^[===^[SORRY!^[===^[ Error while compiling /home/cbwood/Projects/p6-GLib/lib/GLib/Object/Raw/TypeModule.pm6 (GLib::Object::Raw::TypeModule)
const_iX NYI
at /home/cbwood/Projects/p6-GLib/lib/GLib/Object/Raw/TypeModule.pm6 (GLib::Object::Raw::TypeModule):3
This makes 5 aborts over the last 8 weeks. 15:34
To compare, there were no aborts from 11/1/20 to 9/19/21 15:35
sena_kun that's some new bug then... it roughly aligns with new-disp merge maybe? 15:36
Xliff That's my guess.
The problem is... it's a flapper. 15:37
This new one might actually be something that is repeatable, but I am guessing someone has to have run into it.
Repetition steps involves downloading and compiling p6-GLib
MasterDuke nine just fixed a nativecall jit bug yesterday, have you rebuilt since then? 15:38
Xliff Yes. This is fresh.' 15:39
And nope... bug is not repeatable.
=== NativeCall === (2/258) 15:40
Stage start : 0.000
./p6gtkexec: line 63: 234131 Segmentation fault (core dumped) ${EXEC} --stagestats ${EXTRAS} ${INCLUDES} "$@"
That's not good.
Segfault was not repeatable.
dogbert17 p6-GLib, where's this module located? 15:41
MasterDuke does `coredumpctl debug` give you anything?
i'm getting a ton of `No such method 'absolute' for invocant of type 'Slip'`, do i need to be on any particular branch? 15:51
Xliff MasterDuke: Um. No. you shouldn't be. 15:56
Oh wait. Yes.
main, I moved away from master
MasterDuke ah 15:57
Xliff dogbert: github.com/Xliff/p6-GLib
dogbert17 Xliff: thx 15:58
16:21 evalable6 left, linkable6 left 16:22 evalable6 joined
MasterDuke i just got a `No appropriate parametric role variant available for 'NativeCall::Native'` during the compile of GLib::Env 16:23
ah, just got the segv 16:33
nine, dogbert17, Xliff: here's my `coredumpctl debug` output from the segv in P6-GLib's build.sh 16:37
gist.github.com/MasterDuke17/21baf...f2107dbc9f
timo also
Xliff MasterDuke: Thanks. Is that enough for a bug report? 16:44
MasterDuke i'm not sure that data alone is sufficient to debug it, but i was able to repro the segv, so i'd say it's at least worth creating an issue to reference 16:46
Xliff k 16:47
Wouldn't this be MoarVM?
timo if "goto NEXT" segfaults, we're somehow running past the end of a frame's bytecode, probably
MasterDuke Xliff: yeah 16:48
well, there have been frame-related changes recently...
timo: btw, any more data to extract while i still have this coredump open? 16:53
timo phew, let's see. does MVM_dump_bytecode work in a coredump or only in a running process? 16:54
MasterDuke doesn't work in a coredump 16:56
timo ok, well, at least you can print the body of tc->cur_frame and all related stuff, and then walk allllll the way through to the actually in-use spesh candidate (unless it deopted recently, in which case it's null of course) and then use gdb' x command to dump the bytecode as hex or integers 16:57
17:00 SmokeMachine left
MasterDuke `spesh_cand = 0x0` 17:00
gist updated with tc->cur_frame 17:01
timo ok we'll find the bytecode via the static_info link 17:03
MasterDuke tc->cur_frame->static_info->body.bytecode? 17:05
timo that'll be it. also the size of the bytecode should be there as well 17:06
MasterDuke gist updated 17:07
timo for x we can use byte or halfword sizes, since the smallest piece of thing in our bytecode format is 16 bits big
haha, good try but that's not x86 bytecode we store there :D 17:08
MasterDuke oh, ha. right
what's the right modifier? 17:09
timo either xx for bytes as hex, or xh for 16bit halfwords in hex
17:11 leont left
MasterDuke updated 17:12
timo hrmpf. i don't think we have any kind of utility that will trivially just translate a bunch of numbers, or even a bunch of bytes, into a dump, since the current bytecode dumper also wants to find lexical's names and local's types and such 17:16
we do have all these pieces of information we can grab out of the coredump
MVM_dump_backtrace also won't work in the core dump right?
maybe it'll be good enough to find the name, filename, and cuuid, then correlate the data with a spesh log 17:17
MasterDuke right, needs a process
timo hurgleburgle 17:18
now in theory we can rewrite the bytecode dumper in python and make it a gdb plugin/script/command/thingie 17:19
17:23 zostay left, kawaii_ left, tbrowder left 17:24 linkable6 joined
timo MasterDuke: print tc->cur_frame[0].static_info[0].body.cuuid[0]; print tc->cur_frame[0].static_info[0].body.name[0]; print tc->cur_frame[0].static_info[0].body.cu->body.filename[0] 17:48
MasterDuke updated 17:50
timo ok, the filename one is a strand, so we'll want the three entries in the strands array 17:51
MasterDuke updated 17:54
timo hu, that's kinda weird to have .blob_string in there 17:56
it's literaly called that huh
huh the cu's filename ends in a slash? did i get something wrong? 17:57
MasterDuke oh, there's a "precomp" at [3]
timo oh there's 10 strands, not 3 17:58
MasterDuke ha, yeah, just saw that
added the rest 17:59
timo ok i think we can chop off the few bytes at the start of that file and moar --dump it 18:01
18:02 reportable6 left
MasterDuke hm, does gdb have an easy way to write something to a file? 18:03
timo i know it can redirect output from print and such to a file 18:04
also, you can use "python blahblah" to run some python code, that should definitely be able to do it
MasterDuke hm. how much to chop off the front? 18:10
timo up until it says MOARVM i think
MasterDuke oh wait. which file?
timo .../core/precomp/D305AA4813AA36876C6098394DFA56839DEF6BC9/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B 18:11
MasterDuke right. --dump seems to work just fine on it without chopping anything 18:12
timo oh, did we put support for that in perhaps? 18:13
MasterDuke file added 18:17
timo oh no
can you give me the url of the raw?
my browser is having A Time with the huge page
MasterDuke gist.github.com/MasterDuke17/21baf...ecode.dump
timo and can you give me the cuid again? hundred seventy something? 18:19
MasterDuke (gdb) print tc->cur_frame[0].static_info[0].body.cuuid[0] 18:20
$18 = {common = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000', flags2 = 2 '\002', size = 48}, st = 0x556ae0234d20}, body = {storage = {blob_32 = 0x556ae9d55cb0,
blob_ascii = 0x556ae9d55cb0 "142\360\301\177", blob_8 = 0x556ae9d55cb0 "142\360\301\177", strands = 0x556ae9d55cb0, any = 0x556ae9d55cb0}, storage_type = 2, num_strands = 0, num_graphs = 3, cached_hash_code = 0}}
timo ok that seems to be NativeCall.rakumod or whatever
nativecall file line 271, what's there? 18:21
MasterDuke `our role Native[Routine $r, $libname where Str|Callable|List|IO::Path|Distribution::Resource] {`
timo through 279
MasterDuke github.com/rakudo/rakudo/blob/mast...#L271-L279 18:22
timo now that's interesting, the segfault happened inside the implementation of return_i, right?
MasterDuke yeah 18:23
timo but in the bytecode dump of the file i see a return_o at the end 18:24
can you throw out the bytecode dump from the gist so i can open it in the browser again? :D
MasterDuke just back up a revision? 18:26
timo sure, or link me to the actual revision
MasterDuke gist.github.com/MasterDuke17/21baf...00136f508d 18:27
timo oh 18:28
that's after try_return
so the cur_frame wouldn't match up with what operation lives there anyway
so we've kind of lost what frame we were in before 18:30
and if we're segfaulting on "goto next" anyway, we'd not be in bounds of the bytecode, so can't really see what the corresponding invoke op was? 18:31
unless there's randomly something useful in the registers? 18:33
we might be out of luck
MasterDuke gist.github.com/MasterDuke17/21baf...f2107dbc9f added registers, removed bytecode 18:35
timo we could try to dereference all these pointers based on guesses what might live at that address. like trying to get the REPR of all of these addresses, some of them might not segfault 18:41
0x556ae01cd120 is the tc
MasterDuke (gdb) p *(MVMString *)0x556ae29f11b0 18:44
$42 = {common = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000', flags2 = 2 '\002', size = 48}, st = 0x556ae0234d20}, body = {storage = {blob_32 = 0x556ae2a05fb0,
blob_ascii = 0x556ae2a05fb0 "nqp-intify", blob_8 = 0x556ae2a05fb0 "nqp-intify", strands = 0x556ae2a05fb0, any = 0x556ae2a05fb0}, storage_type = 2, num_strands = 0, num_graphs = 10, cached_hash_code = 16278759805873085490}}
that was r10
timo 0x556ae2* is where some of the string blobs live
ah very good 18:45
so we might have just returned from the nqp-intify dispatcher
that definitely explains why we're in return_i 18:48
18:54 leont joined 18:59 patrickb left 19:06 zostay joined, tbrowder joined, SmokeMachine joined 19:08 kawaii_ joined 20:04 reportable6 joined
nine Are we in a native callback? 20:07
What's on top of tc->stack_top?
No, backtrace doesn't look like native callback 20:08
MasterDuke (gdb) p *tc->stack_top 20:14
$47 = {prev = 0x556ae3e1e500, kind = 3 '\003', orig_kind = 112 'p'}
21:51 evalable6 left, linkable6 left 21:53 evalable6 joined 22:46 Colt joined
Geth rakudo/perhaps-error: 10026cff96 | (Elizabeth Mattijsen)++ | 2 files
Make class A does B{ } error more awesome

Adds the line "Perhaps you forgot a space before the { ?" to the otherwise rather obscure error message caused by lack of whitespace between the role name and the opening curly
   $ raku -e 'role A{ ... }; class B does A{ ... }'
... (7 more lines)		 23:14
rakudo: lizmat++ created pull request #4649:
Make class A does B{ } error more awesome
23:53 linkable6 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!