|
🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
|
01:05
[Coke] left
01:07
[Coke] joined
06:29
coverable6 left,
evalable6 left,
shareable6 left,
bisectable6 left,
linkable6 left,
nativecallable6 left,
greppable6 left,
benchable6 left,
tellable6 left,
sourceable6 left,
quotable6 left,
bloatable6 left,
releasable6 left,
unicodable6 left,
notable6 left,
committable6 left
06:32
linkable6 joined,
shareable6 joined,
bisectable6 joined,
unicodable6 joined,
releasable6 joined
06:33
nativecallable6 joined,
committable6 joined,
evalable6 joined,
coverable6 joined,
notable6 joined,
benchable6 joined,
quotable6 joined
06:34
sourceable6 joined,
greppable6 joined,
tellable6 joined,
bloatable6 joined
07:25
[TuxCM] joined
|
|||
| timo | it's still running without having crashed | 08:57 | |
|
10:39
finanalyst joined
11:47
finanalyst left
13:21
[TuxCM] left
13:35
[TuxCM] joined
13:54
finanalyst joined
15:21
MasterDuke joined
|
|||
| MasterDuke | ugexe, timo: have you seen github.com/rakudo/rakudo/issues/5872 ? seems like maybe it's actually a problem in App::Prove6? or a precomp bug? or a run/locking bug? | 15:23 | |
|
15:24
[TuxCM] left
|
|||
| timo | can you get the stack traces from the other threads? 2, 4 and 6 are interesting | 15:25 | |
| MasterDuke | heh. i forgot to get them all and closed my gdb session overnight | ||
| i'll try to repro | 15:26 | ||
| timo | i do think we have a bug with "run" or maybe Proc::Async where making too many async processes may just create an army of workers that are blocking on something and deadlocking that way | ||
| but in this case there are not that many | 15:28 | ||
| if you can get an rr recording, that would also include subprocesses, which depending on what the actual bug is could also be important to have | |||
| but you can also just attach to the subprocesses at the point when it's hanging | 15:29 | ||
| MasterDuke | it didn't take too long to happen last time, if i can't get it in a reasonable amount of time i'll trying running it under rr on the desktop | 15:30 | |
| timo | rr has its "chaos mode" as well which can make issues come up faster | 15:32 | |
|
15:32
finanalyst left
|
|||
| MasterDuke | ah, it just hung | 15:34 | |
| gist.github.com/MasterDuke17/a147c...6ccf3ecc2b | 15:35 | ||
| timo | the workers all look like they're waiting for a task to appear on their queue | 15:37 | |
| we don't really have like, a debug command to list stuff on the libuv event loop | 15:38 | ||
| MasterDuke | i've never tried to look in the uv event loop | 15:39 | |
| timo | since this is working with subprocesses, there'd be some file handles / pipes with read tasks where something coming from the subprocess, or the input handle becoming writable, would cause things to move further | ||
| MasterDuke | should i get a rakudo backtrace in the various threads? | 15:40 | |
| timo | you can. my assumption is they are all in ThreadPoolScheduler's file, the different "start bla launcher" functions | ||
| can you look at the processes that live under this rakudo process? like with `ps faux` | 15:45 | ||
| you could attach to them and see what they are up to | |||
| MasterDuke | gist updated | 15:46 | |
|
15:46
finanalyst joined
|
|||
| MasterDuke | gist updated again | 15:48 | |
|
15:49
finanalyst_ joined
|
|||
| MasterDuke | no subprocesses | 15:49 | |
| timo | ok, next step would probably be to look exactly at App::Prove6 there | 15:51 | |
|
15:51
finanalyst left
|
|||
| MasterDuke | lunchtime, so might be afk on and off. but i'll leave the gdb session open and check the logs if there's anything else i should run | 15:52 | |
| timo | ok | 15:53 | |
| MasterDuke | but i think github.com/Leont/app-prove6/blob/m...akumod#L52 is the line it's at | ||
| leont | The real work there happens in TAP::Harness.run really | 16:06 | |
|
16:15
finanalyst_ left
|
|||
| timo | right, the question is what's not finishing up correctly, and that's tricky to answer from within C / gdb | 16:15 | |
|
16:16
finanalyst_ joined
|
|||
| MasterDuke | yeah, from the backtraces it doesn't look like any of the threads are in TAP::Harness at the point of the hang | 16:16 | |
| timo | right, everything in TAP::Harness is set up with like, taps on supplies and such | 16:19 | |
| i'm not exactly sure which different Source and Handler classes are relevant to this use case | |||
| do you have it as a rr recording btw? or just the current state? | 16:20 | ||
| MasterDuke | just the current state | ||
| but it reproed pretty quickly, i can try to get it in rr on the desktop | 16:21 | ||
| timo | we could have it in "rr record" and also turn MVM_COVERAGE_LOG=blabla on | 16:22 | |
|
16:33
finanalyst_ left
|
|||
| MasterDuke | hm, taking longer to repro there | 16:36 | |
| timo | i've been running the nqp test suite nonstop since yesterday and not a repro in sight :) | 16:42 | |
| MasterDuke | i usually *also* run a rakudo spectest in a loop to increase load | 16:45 | |
| hm. i wonder if it needs MVM_JIT_DISABLE=1 on the desktop to repro... | 16:52 | ||
| timo | is it arm64/aarch64 on the other machine? | 17:00 | |
| MasterDuke | no, x86 | 17:01 | |
| timo | ah, 32bit | ||
| MasterDuke | x86-64 | 17:02 | |
| zen2 | |||
| hm. if i have a rr record running and raku hangs, will ctrl-c safely stop and save the recording? | 17:06 | ||
| timo | yeah | 17:08 | |
|
17:08
finanalyst_ joined
|
|||
| MasterDuke | well, i have an aarch64 recording, want that? | 17:13 | |
| but rr definitely is not quite a solid on this system | 17:20 | ||
| timo | i'm not sure if i can run an rr replay on my machine, but i also have an aarch64 qemu VM now | 17:23 | |
| MasterDuke | what's that website you use for sending files? | 17:24 | |
| timo | maybe sendfiles.dev/ | 17:25 | |
| MasterDuke | i know it's pretty late, but news.ycombinator.com/item?id=43751076 would be a good place for a raku comment | 18:40 | |
| unrelated. i looked at the slides for archive.fosdem.org/2018/schedule/e...rivatives/ but not the talk yet. anybody know if it's relevant for rakudo/nqp/moarvm? | 18:41 | ||
|
18:54
finanalyst_ left,
finanalyst_ joined
19:21
MasterDuke left
19:28
[TuxCM] joined
21:02
[TuxCM] left
|
|||
| ab5tract | ugexe: I just finished a first pass at Resource::Wrangler. I don't know what I was complaining about, really, it's not hard to set up the transfer of the file to a new path | 21:34 | |
| but I figure it is useful to get the corner cases covered in an ecosystem module | |||
| (none of which are covered by my current implementation, but hey :) ) | |||
|
21:54
finanalyst_ left
|
|||
| ab5tract | come to think of it, these corner cases are probably already well taken care of in the distibution internals | 21:54 | |
| ugexe | ab5tract: you'll want to account for multiple version/api/auth | 22:15 | |
| i.e. the $prefix should probably default to something like like "/tmp/{nqp::sha1($?DISTRIBUTION.Str)}" | 22:16 | ||
| otherwise different versions can potentially overwrite the files underneath each other | 22:18 | ||
| github.com/raku-community-modules/...od#L31-L35 | 22:25 | ||
| there is how i implemented in openssl long ago... it would fall victim to the version issue i just described | 22:26 | ||
| it could probably use your module instead | |||
|
23:22
guifa joined
23:46
guifa left
|
|||