nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] GCC 8 pre-releases have escaped...


From: Ralph Corderoy
Subject: Re: [Nmh-workers] GCC 8 pre-releases have escaped...
Date: Sun, 11 Feb 2018 00:51:02 +0000

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: address@hidden
    From: address@hidden

    ==> 5781 <==
    Date: Sun, 31 Jul 2011 00:00:01 +0100
    To: address@hidden, address@hidden
    From: address@hidden (Ralph Corderoy)

    ==> 5782 <==
    Date: Sun, 31 Jul 2011 00:00:01 +0100
    To: address@hidden
    From: address@hidden

    ==> 5783 <==
    Date: Sun, 31 Jul 2011 00:00:01 +0100
    To: address@hidden
    From: address@hidden

    ==> 5784 <==
    Date: Sun, 31 Jul 2011 00:00:01 +0100
    To: address@hidden
    From: address@hidden

    ==> 5785 <==
    Date: Sun, 31 Jul 2011 00:00:01 +0100
    From: Not Me1 <address@hidden>
    To: address@hidden
    $

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, 
        address@hidden <dat>, address@hidden) 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]