SIGSEGV in logfile_sub_source::rebuild_index right after a file passes 134,217,728 (2^27) lines

Disclosure first: I develop a large-file text viewer myself (UwView / UwView Pro), and lnav appears in pages I have already published — a comparison page and a companion article about lnav and PilotEdit:

• https://uvp.y42u.net/en/benchmarks-en/
• https://uvp.y42u.net/en/blog/uvp-pilotedit-lnav-48gb-en/

I would rather have the right result on those pages than the one I have now, which is why I am reporting this properly instead of leaving a mark on a page.

lnav version

0.14.1

Describe the bug

lnav dies with SIGSEGV while building the index, on a file with 892,239,125 lines. Reproduced three times (2026-09-08, 2026-09-11, 2026-09-12).

In all three crash logs, the last thing the LOG view reports before the crash is the same number:

vc_title=LOG; vc_y=2; lv_top=133999860; lv_left=0; lv_height=-9; lv_selection=-1; inner_height=134217728

134,217,728 is 2^27 exactly, and the index had just reached 134,999,869 lines. It is the same value in all three logs, and the crash follows immediately.

That suggests the boundary is the line count, not the file size — which also explains why a 10 GB file of the same kind completes without trouble: it has about 100 million lines, under 2^27. The 48 GB file has 892 million, 6.6x over.

I am not claiming to know which limit this is; I only know the number that appears right before every crash.

Backtrace:

Received signal: 11
0   lnav                       _ZL7sigabrtiP9__siginfoPv + 256
1   lnav                       fatal_handler + 312
2   libsystem_platform.dylib   _sigtramp + 56
3   lnav                       logfile_sub_source::rebuild_index(...) + 5068
4   lnav                       rebuild_indexes(...) + 2756
5   lnav                       looper() + 16284
6   lnav                       main + 26168

To Reproduce

Steps to reproduce the behavior:

1. Produce a single text file with more than 134,217,728 lines. Mine is the OpenStreetMap Japan extract expanded to XML: osmium cat japan-latest.osm.pbf -o japan-latest.osm — 51,254,526,392 bytes, 892,239,125 lines, one tag per line, short and uniform, UTF-8, no timestamps.
2. lnav japan-latest.osm
3. First paint appears in about 1.4 s. Leave it indexing.
4. At around 2 minutes (09:00:25 -> 09:02:43 on the last run, 2 min 18 s), lnav crashes. The GURU MEDITATION handler fires and writes a crash log.

Expected behavior

Either index the file, or stop with an error saying the file is too large. A SIGSEGV is the part I think is worth fixing, whatever the answer is about supported sizes.

Environment

lnav 0.14.1
MacBook Air, Apple M4, 32 GB RAM
Darwin 25.3.0, arm64 (T8132)
LANG=ja_JP.UTF-8
file on an external USB SSD

Two things I should say plainly

1. This file is not a log. An OSM XML dump is outside what lnav is for, and if the answer is "that is not supported", that is fair and I will say so on my page. But a SIGSEGV is different from a refusal, which is why I am filing it.
2. While indexing, lnav reports roughly 950,000 "out-of-time-order lines" on every pass. The file has no timestamps at all, so lnav may be doing a great deal of work that has no meaning for this input. That may be a separate issue, or it may be related.

Also worth saying: the first paint was 1.4 s, the fastest of every tool I measured. lnav shows you something almost immediately.

What I can do

I have the file and the machine, and it reproduces every time. I am happy to run an instrumented build, attach a debugger, or send the full crash logs (about 325 KB each, three of them). I have also sent one via lnav -m crash upload.

Thanks for lnav.