Crash when combining --unique --count-only --matches with large files

[Zer0-Tolerance]

Hi Liz,

Thanks for implementing the feature request ! After doing some testing I've run into a bug when you do this:
rak keyword --count-only --unique --matches /tmp/huge-file.json => this crashes instantly
rak keyword --count-only --unique --matches /tmp/small-file.txt => this works
rak keyword --count-only /tmp/huge-file.json => this works

I'm using rak version

rak --version 
rak - provided by App::Rak 0.3.8, running Raku 6.d with Rakudo 2024.05. 

Any idea why it crashes with huge files only ?

[lizmat]

No idea.

How huge is the JSON file?

Could you provide the output with --dont-catch ?

[Zer0-Tolerance]

File size is 300 MB

rak -i keyword --count-only --unique --matches /tmp/huge-file.json --dont-catch
MoarVM panic: Internal error: invalid thread ID -412615384 in GC work pass

[lizmat]

Ok, looks like a memory corruption in MoarVM :-(. Multi-threading is hard!

Does it also crash with --degree ?

OOC, which version of Rakudo are you using?

[Zer0-Tolerance]

Ok, looks like a memory corruption in MoarVM :-(. Multi-threading is hard!

Does it also crash with --degree ?
nope it doesn't crash with --degree=1 and crash in 80 % of the cases when --degree=2 so yes very likely a multithreading issue

OOC, which version of Rakudo are you using?
Built on MoarVM version 2024.05 running on OSX 13.6.9 Arm

[lizmat]

Hmmm --matches appears to be a non-existent argument? Do you have a shortcut for it?

Also: you don't appear to be using any JSON specific functionality. So I tried to do this on a 800MB text file I have for this purpose. It passes, but on MacOS with Apple Silicon.

Are you running by chance on Intel hardware? If so, could you try running it with MVM_EXPR_JIT_DISABLE=1 ?

If that makes a difference, then please upgrade to 2024.07. We identified issues in the expression JIT compiler: 1. it caused instability, and 2. overall, it slowed down execution on Intel hardware. So it has been disabled since the 2024.07 release.

[Zer0-Tolerance]

Hmmm --matches appears to be a non-existent argument? Do you have a shortcut for it?

Also: you don't appear to be using any JSON specific functionality. So I tried to do this on a 800MB text file I have for this purpose. It passes, but on MacOS with Apple Silicon.

Are you running by chance on Intel hardware? If so, could you try running it with MVM_EXPR_JIT_DISABLE=1 ?

If that makes a difference, then please upgrade to 2024.07. We identified issues in the expression JIT compiler: 1. it caused instability, and 2. overall, it slowed down execution on Intel hardware. So it has been disabled since the 2024.07 release.

My bad for the arg I have a shortcut for --matches-only and I'm running on Apple Silicon too

[lizmat]

Hmm.. then I would suggest you upgrade to 2024.07 anyway: there's been some other work on MoarVM as well, and maybe, just maybe it got fixed.

[Zer0-Tolerance]

I will upgrade for sure, but indeed with a different JSON file of 200 mb it seems to work fine. With another file of just 56 MB it keeps crashing.

[Zer0-Tolerance]

I'm attaching the small file I use to reproduce the bug
xab.gz
with : rak -i abc --count-only --unique --matches xab

[Zer0-Tolerance]

I've manage to get an error that is a bit more useful:

Unhandled exception in code scheduled on thread 11
This exception is not resumable
  in block  at /Users/user/.rakubrew/versions/moar-2024.07/share/perl6/site/sources/423D5F8D02036D03B5702942C8112298C42E64D2 (ParaSeq) line 796
  in method run at /Users/user/.rakubrew/versions/moar-2024.07/share/perl6/site/sources/423D5F8D02036D03B5702942C8112298C42E64D2 (ParaSeq) line 193
  in block  at /Users/user/.rakubrew/versions/moar-2024.07/share/perl6/site/sources/423D5F8D02036D03B5702942C8112298C42E64D2 (ParaSeq) line 1636
  in block  at /Users/user/.rakubrew/versions/moar-2024.07/share/perl6/site/sources/423D5F8D02036D03B5702942C8112298C42E64D2 (ParaSeq) line 789

fish: Job 1, 'rak -i abc -u -c -m /Users/user…' terminated by signal SIGSEGV (Address boundary error)

There must be a link with paraseq !

[Zer0-Tolerance]

if you run this cmd several time you will get different number of matches:

rak -i abc --count-only --matches-only xab
1082 matches in 1 file
rak -i abc --count-only --matches-only xab
1084 matches in 1 file
rak -i abc --count-only --matches-only xab
1085 matches in 1 file

but if you add --degree=1 then you always get 1084. There is something wrong with multithreading

[lizmat]

There is something wrong with multithreading

Interesting. The count-only feature uses the :mapper: feature of the "rak" module, and that's supposed to be thread-safe...

[lizmat]

There must be a link with paraseq !

Indeed. But ParaSeq just uses Raku's features, albeit in a more optimal way than the standard .hyper functionality. So maybe it's tickling some race condition that otherwise doesn't get tickled.

[lizmat]

rak -i abc --count-only --matches-only xab

OOC, why the --matches-only ? Especially if you have a fixed string?

[lizmat]

This exception is not resumable

Sadly this doesn't tell it what the exception was. This happens on .resume :-(