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: [email protected]
From: [email protected]
==> 5781 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: [email protected], [email protected]
From: [email protected] (Ralph Corderoy)
==> 5782 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: [email protected]
From: [email protected]
==> 5783 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: [email protected]
From: [email protected]
==> 5784 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: [email protected]
From: [email protected]
==> 5785 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
From: Not Me1 <[email protected]>
To: [email protected]
$
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
