Re: vi -r crash, netbsd-9 amd64

[Paul Ripke <stix%stix.id.au@localhost>]

On Tue, Oct 11, 2022 at 07:59:27PM -0000, Christos Zoulas wrote:
> In article <Y0U26PzRfvofhlVY@slave.private>,
> Paul Ripke  <stix%stix.id.au@localhost> wrote:
> >Not sure if it's worth logging or not, but I just had 'vi -r' segv.
> >System is amd64, NetBSD 9.3_STABLE (SLAVE) #15: Sat Sep 17 23:12:17 AEST 2022
> >
> >Core was generated by `vi'.
> >Program terminated with signal SIGSEGV, Segmentation fault.
> >#0  0x00007936f95693d4 in ?? () from /lib/libc.so.12
> >(gdb) bt
> >#0  0x00007936f95693d4 in ?? () from /lib/libc.so.12
> >#1  0x00007936f954a403 in mbrtowc_l () from /lib/libc.so.12
> >#2  0x00000001cd40edba in default_char2int.isra ()
> >#3  0x00000001cd4518d3 in db_get ()
> >#4  0x00000001cd447c5f in vs_columns ()
> >#5  0x00000001cd447df9 in vs_screens ()
> >#6  0x00000001cd44850e in vs_sm_next ()
> >#7  0x00000001cd449891 in vs_sm_fill ()
> >#8  0x00000001cd446019 in vs_paint ()
> >#9  0x00000001cd447730 in vs_refresh ()
> >#10 0x00000001cd445d86 in vs_resolve ()
> >#11 0x00000001cd442916 in vi ()
> >#12 0x00000001cd42bb26 in editor ()
> >#13 0x00000001cd4537ef in main ()
> >
> >Worth logging?
> 
> I don't see any changes that could have fixed it... But if you can reproduce
> it with symbols, it would be more useful...

Well, that was interesting. I noticed that vi hit ~6.5GiB rss,
and took quite a while to crash (minutes) creating a ~2MiB core. With
'-g' added to the vi build:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007b16a03693d4 in ?? () from /lib/libc.so.12
(gdb) bt
#0  0x00007b16a03693d4 in ?? () from /lib/libc.so.12
#1  0x00007b16a034a403 in mbrtowc_l () from /lib/libc.so.12
#2  0x00000001b440edba in default_char2int (str=<optimized out>, len=1702453612, cw=0x7b16a13001e8, tolen=0x7f7fff483548, 
    dst=0x7f7fff483540, enc=<optimized out>, sp=<optimized out>)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/common/conv.c:142
#3  0x00000001b44518d3 in db_get (sp=sp@entry=0x7b16a12da000, lno=<optimized out>, flags=flags@entry=0, 
    pp=pp@entry=0x7f7fff4835b8, lenp=lenp@entry=0x7f7fff4835c8)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/common/vi_db1.c:180
#4  0x00000001b4447c5f in vs_columns (sp=sp@entry=0x7b16a12da000, lp=<optimized out>, lp@entry=0x0, lno=lno@entry=39, 
    cnop=cnop@entry=0x0, diffp=diffp@entry=0x0) at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_relative.c:122
#5  0x00000001b4447df9 in vs_screens (sp=0x7b16a12da000, lno=39, cnop=cnop@entry=0x0)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_relative.c:83
#6  0x00000001b444850e in vs_sm_next (sp=<optimized out>, p=0x7b16a12ce920, t=0x7b16a12ce950)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_smap.c:1063
#7  0x00000001b4449891 in vs_sm_fill (sp=sp@entry=0x7b16a12da000, lno=<optimized out>, pos=pos@entry=P_MIDDLE)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_smap.c:246
#8  0x00000001b4446019 in vs_paint (sp=sp@entry=0x7b16a12da000, flags=flags@entry=3)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_refresh.c:184
#9  0x00000001b4447730 in vs_refresh (sp=sp@entry=0x7b16a12da000, forcepaint=forcepaint@entry=1)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_refresh.c:99
#10 0x00000001b4445d86 in vs_resolve (sp=sp@entry=0x7b16a12da000, csp=0x7b16a12da000, csp@entry=0x0, 
    forcewait=forcewait@entry=0) at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vs_msg.c:697
#11 0x00000001b4442916 in vi (spp=spp@entry=0x7f7fff483b30) at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/vi/vi.c:104
#12 0x00000001b442bb26 in editor (wp=0x7b16a1300000, argc=<optimized out>, argv=<optimized out>)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/common/main.c:436
#13 0x00000001b44537ef in main (argc=3, argv=0x7f7fff483da8)
    at /home/netbsd/netbsd-9/src/external/bsd/nvi/dist/cl/cl_main.c:134

How about that?!? vi recovery files are berkeley db btrees (actually, no):

/var/tmp/vi.recover/vi.yjuFln: Berkeley DB 1.85/1.86 (Btree, version 3, native byte-order)

Frame 2 above suggests a ~1.7GiB record, which is amazing considering
the size of the file:

-rw-------  1 stix  wheel  7168 Sep 27 18:51 /var/tmp/vi.recover/vi.yjuFln

Looks like we build nvi with -DUSE_BUNDLED_DB, so, on a lark:

slave:ksh$ db btree /var/tmp/vi.recover/vi.yjuFln
        
db: Error dumping database: Invalid argument

Ok. Shouldn't that be possible? Huh. Looking at the code, the files are
actually not BTREE, or HASH, but actually DB_RECNO. Which db(1) doesn't
support.

Mucked around trying the ex "pre" (preserve) command and then 'kill -9' on vi,
"vi -r", etc, and it seemed to work fine. The recovery file that causes the
crash was left behind after a kernel panic. There's nothing important in it,
I just tried recovery as suggested, and was surprised by vi crashing.
There's probably some bug here, but I don't think I'm going to spend any more
time on it without a nice repro.

Cheers,
-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.