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: ra...@inputplus.co.uk From: ra...@inputplus.co.uk ==> 5781 <== Date: Sun, 31 Jul 2011 00:00:01 +0100 To: not-...@example.com, ra...@inputplus.co.uk From: ra...@inputplus.co.uk (Ralph Corderoy) ==> 5782 <== Date: Sun, 31 Jul 2011 00:00:01 +0100 To: ra...@inputplus.co.uk From: ra...@inputplus.co.uk ==> 5783 <== Date: Sun, 31 Jul 2011 00:00:01 +0100 To: ra...@inputplus.co.uk From: ra...@inputplus.co.uk ==> 5784 <== Date: Sun, 31 Jul 2011 00:00:01 +0100 To: ra...@inputplus.co.uk From: ra...@inputplus.co.uk ==> 5785 <== Date: Sun, 31 Jul 2011 00:00:01 +0100 From: Not Me1 <not-...@example.com> To: not-...@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