Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Clean 'make check' against gcc
-fsanitize=address,undefined (Richard Kettlewell)
2. Re: Clean 'make check' against gcc
-fsanitize=address,undefined (Richard Kettlewell)
3. Re: nnrpd given the same PID as innfeed (Richard Kettlewell)
4. Test rig (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Sat, 27 Jun 2015 15:44:53 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Clean 'make check' against gcc
-fsanitize=address,undefined
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 2015-06-26 19:23, Julien ?LIE wrote:
> Hi Richard,
>
>>> The current code is:
>>> now = (tv.tv_sec - base.tv_sec) * 1000;
>>> now += (tv.tv_usec - base.tv_usec) / 1000;
>>
>> That doesn't help. In the current code the multiplication is done in
>> the signed type. If it overflows (as it will after a few weeks, on
>> 32-bit platforms) then we are already into undefined behavior (C99
>> s6.5#5).
>
> Then, so as to prevent overflows, maybe we should call TMRsummary() more
> often, or force it when the timer is near to overflowing. I believe the
> issue only appears when innconf->timer is 0 because calls to
> TMRsummary() are not done in this configuration.
>
> Oh, I see that the default value for innconf->timer is 0 whereas the
> inn.conf documentation indicates that "enabling this is highly
> recommended". Maybe we could change the default value for INN 2.6.0!
> Suggestion: 600s (10mn).
>
> If set to 0, maybe we could force the log anyway when it reaches 42
> days? It won't do much harm, and it will prevent these overflows.
>
> Any thought about that?
(See below.)
>>> If I follow your suggestion with tv=2,2s and base=1,4s:
>>>
>>> now = (unsigned long)(tv.tv_sec - base.tv_sec) * 1000u;
>>> usec = tv.tv_usec - base.tv_usec; /* maybe -ve */
>>> msec = usec / 1000; /* still maybe -ve */
>>> now += (unsigned long)msec;
>>> I believe it would result in:
>>> now = 1000 + (-200+UINT_MAX+1) which would overflow because
>>> of the negative msec being converted to unsigned, instead of:
>>
>> Overflow behavior for unsigned types (including conversion of negative
>> values to unsigned types) is defined: the result is the residue modulo
>> 2^n (C99 s6.2.5#9). The result with the patch is therefore 800.
>
> OK, thanks.
> Patch applied.
>
> Do you believe something similar should be done for the computation of
> OVERartcheck and OVERtime in nnrpd code?
> and statistics->busy as well as total in backends/overchan.c?
In principle yes, but I think overflow will take much longer.
> and STATUSgettime() in innd/status.c?
I think so, yes.
In all cases, perhaps the best approach is to use 64-bit types
throughout? That pushes all overflows nearly 300M years into the future.
ttfn/rjk
------------------------------
Message: 2
Date: Sat, 27 Jun 2015 15:48:01 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Clean 'make check' against gcc
-fsanitize=address,undefined
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 2015-06-25 21:20, Julien ?LIE wrote:
>>> "-fsanitize=address,undefined" did not trigger any warning for them?
>>
>> It didn't. I expect they don't access the uninitialized parts of the
>> structure. Dynamic analysis can only reveal limited classes of issues...
>
> Such accesses could be something that static analysis could find,
> though. What has already been initialized is normally known. At least
> for the kind of calls we do (no dynamic variable). Isn't it strange
> that static analysis tools do not manage to catch that?
The Clang analyser is quite incomplete too!
ttfn/rjk
------------------------------
Message: 3
Date: Sat, 27 Jun 2015 16:21:53 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: nnrpd given the same PID as innfeed
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 25/06/2015 20:43, Julien ?LIE wrote:
> Following my previous message:
>
>>> The repeated PIDs and consistently growing elasped time is the clue
>>> that got me there. Evidently it is revisiting the same PROCtable
>>> entries.
>>
>> After almost 6 hours of run, still no realloc or calls of PROCreap
>> and PROCscan that change PROCtable. And no "exit 1" errors.
>
> After a week, still no error. Therefore, I believe you managed to fix
> the issue. Thanks again, Richard!
Glad to hear it!
ttfn/rjk
------------------------------
Message: 4
Date: Sat, 27 Jun 2015 18:08:46 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Test rig
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 2015-06-20 10:27, Richard Kettlewell wrote:
> Patch attached. 'make check' no longer leaks semaphores. I modified my
> test rig to use buffindexed in one test so the code has been run in its
> proper environment at least once!
I've alluded to this test rig a couple of times. It's now mature enough
that I'm prepared to let other people see it. It can be found at:
https://github.com/ewxrjk/inntest
Some caveats:
- It remains a work in progress and is likely to be unstable.
- It's somewhat tied to my local environment, though I've
tried to keep this a matter of configuration.
- I've not tried running it outside Debian sid.
Coverage levels:
- Most RFC3977 commands are exercised at least once.
- No RFC4644 commands are exercised.
- All RFC6048 commands are exercised at least once.
- Coverage of INN configuration space is low.
- Coverage of INN code is low.
Feedback welcome.
ttfn/rjk
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 73, Issue 15
*******************************************
