Hi Ken,
Looks like that was introduced in ff5eb06992. It looks like ... that
gets called if it is parsing a component with multiple addresses and
the first one is NOT one of your local mailboxes, but later ones are?
Maybe. Ralph, does that match the description of your message?
It's in the right area. If I whittle down the scan format, and the
emails, whilst keeping a SEGV then I think the problem moves, but I
expect it's still the same root cause.
All the emails in the folder:
$ head *
==> 5780 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: ralph@inputplus.co.uk
From: ralph@inputplus.co.uk
==> 5781 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: not-me0@example.com, ralph@inputplus.co.uk
From: ralph@inputplus.co.uk (Ralph Corderoy)
==> 5782 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: ralph@inputplus.co.uk
From: ralph@inputplus.co.uk
==> 5783 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: ralph@inputplus.co.uk
From: ralph@inputplus.co.uk
==> 5784 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: ralph@inputplus.co.uk
From: ralph@inputplus.co.uk
==> 5785 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
From: Not Me1 <not-me1@example.com>
To: not-me2@example.com
$
Printing the sixth has trouble.
$ uip/scan -forma '%<{date}d%>%<(mymbox{from})f%<(mymbox{to})t%>%>'
dft
dft
dft
dft
dft
Segmentation fault (core dumped)
gdb says
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7877933 in free () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7877933 in free () from /usr/lib/libc.so.6
#1 0x000055555555ef4a in fmt_scan (format=<optimized out>,
scanlp=<optimized out>, width=114,
dat=dat@entry=0x55555557b810 <dat>, callbacks=callbacks@entry=0x0) at
sbr/fmt_scan.c:1134
#2 0x0000555555559ad3 in scan (inb=<optimized out>, innum=5785, outnum=0,
nfs=<optimized out>,
width=<optimized out>, curflg=<optimized out>, unseen=0,
folder=0x5555555a5a00 "/home/tmp/1518309035.144095754", size=0,
noisy=1, scanl=0x7fffffffbd78)
at uip/scansbr.c:338
#3 0x0000555555559543 in main (argc=<optimized out>, argv=<optimized out>)
at uip/scan.c:282
All six are required, the comment in the second is needed. This all
suggests it's the access pattern that's the problem, and that there are
many possible problem patterns.
I am wondering if the buffer reuse in scansbr.c is still warranted;
should we just accept the price of a bunch of malloc/free calls?
I'd prefer correctness first, and understandability second so we have a
good chance of reasoning at its correctness. Then, when it's slow,
there's a solid base for incremental improvements whilst keeping the
other invariants.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers