Segmentation fault on searching firefox cache

[itscool900]

This is a bit of a moot issue, and I don't know exactly what is causing it, but...
For a particular file in my Firefox profile (cache2/entries/F718DFFF0D18D8EF545D4B43B1C1B5B5A325B4F5), ugrep segfaults when I search for 'window' in it.
I've tried deleting line-by-line to see where the error is, but results are inconsistent.

Probably related is the fact that it tries to print out data from it, even though I'm pretty sure it's a binary file. (If you delete the first line it is treated as a binary file.)

[WavyEbuilder]

Could you get a backtrace by chance? What platform are you running under? Do you have systemd?

[itscool900]

Sorry, should have specified.
Platform is Void Linux (musl), so no systemd.
And here is the output of gdb:

[Switching to LWP 28081]
memcpy () at src/string/x86_64/memcpy.s:18
warning: 18	src/string/x86_64/memcpy.s: No such file or directory
(gdb) bt
#0  memcpy () at src/string/x86_64/memcpy.s:18
#1  0x0000555555594937 in ?? ()
#2  0x00005555555810ad in ?? ()
#3  0x000055555558a1c5 in ?? ()
#4  0x00007ffff7b27db3 in ?? () from /lib/libstdc++.so.6
#5  0x00007ffff7fbd90e in start (p=0x7ffff7733ac8)
    at src/thread/pthread_create.c:207
#6  0x00007ffff7fc3d11 in __clone () at src/thread/x86_64/clone.s:22
Backtrace stopped: frame did not save the PC

I don't know how to use automake, but if you give me instructions to compile with debugging symbols, I can show you what gdb says.

[genivia-inc]

Can you share the input file with me? Please email to contact@genivia.com thanks!

Probably related is the fact that it tries to print out data from it, even though I'm pretty sure it's a binary file. (If you delete the first line it is treated as a binary file.)

This is not to be expected, because binary detection is not based on lines. A block of data is read to check for text properties in that block. So removing a line can't make the file suddenly be detected as binary. Are you using ug directly on the file and with what options?

[genivia-inc]

If the file is too big, then let me know. In that case I will set up a dropbox for you when you contact me by email.

It's a strange scenario. There are many tests performed to extensively test ugrep.

[genivia-inc]

I'd really like to get to the bottom of this.

There are lots of tests on ugrep that we run on text/binary input that does not replicate this problem. I can't replicate it. So if this is a problem, it is very specific to this cache file.

One thing I want to do on my end for the upcoming ugrep 7.7.0 release is to update binary detection for huge files, so your scenario cannot happen again.