Opened 20 months ago

Last modified 20 months ago

#18389 new bug

[TextSearch] crash on files with long lines.

Reported by: bipolar Owned by: phoudoin
Priority: normal Milestone: Unscheduled
Component: Applications/TextSearch Version: R1/beta4
Keywords: Cc:
Blocked By: Blocking:
Platform: x86

Description (last modified by bipolar)

Steps to reproduce:

Save a copy of system_logging.html locally, run > TestSearch system_logging.html, type "test" on the search input box, hit enter.

Will attach .report file next.

Could be related to #17011, but I'm not entirely sure (this one consistenly shows crash on _IO_vfscanf).

Attachments (1)

TextSearch-4618-debug-26-04-2023-06-21-44.report (32.4 KB ) - added by bipolar 20 months ago.
Crash on beta4 32 bits

Download all attachments as: .zip

Change History (10)

by bipolar, 20 months ago

Crash on beta4 32 bits

comment:1 by bipolar, 20 months ago

Description: modified (diff)

comment:2 by bipolar, 20 months ago

Description: modified (diff)

comment:3 by diver, 20 months ago

I think trying to play a video in VLC also crashes in _IO_vfscanf.

comment:4 by waddlesplash, 20 months ago

We should probably upgrade or replace the vfscanf implementation.

comment:5 by phoudoin, 20 months ago

I think here it's a bug in TextSearch, in Grepper.cpp. The line buffer handed to sscanf() to extract the filename, line number and position is sized to B_PATH_NAME_LENGTH * 2. Which gives only 2048 max, AFAICT.

If the actual line read from grep output is longer than that, I fear that there is no \0 at end of the line buffer, which lead to sscanf() stepping outside memory boundary and therefore crash.

Last edited 20 months ago by phoudoin (previous) (diff)

comment:6 by phoudoin, 20 months ago

Another way to fix it is to use strtok() instead of sscanf() to parse the grep ouput lines.

in reply to:  5 ; comment:7 by madmax, 20 months ago

Replying to phoudoin:

If the actual line read from grep output is longer than that, I fear that there is no \0 at end of the line buffer

The line comes from fgets, which should put the NULL at the end.

FWIW, I cannot reproduce it in hrev56931 x86_64.

in reply to:  7 comment:8 by bipolar, 20 months ago

Replying to madmax:

FWIW, I cannot reproduce it in hrev56931 x86_64.

Indeed, it doesn't crashes on beta4 64 bits either. But does easily on beta4 32 bits.

comment:9 by madmax, 20 months ago

Platform: Allx86
Note: See TracTickets for help on using tickets.