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: nnrpd given the same PID as innfeed (Julien ?LIE)
2. Re: Clean 'make check' against gcc
-fsanitize=address,undefined (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Jun 2015 21:43:36 +0200
From: Julien ?LIE <[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; format=flowed
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!
--
Julien ?LIE
? Depuis que j'ai chang? mon clavier qwerty pour un clavier azerty,
je tape deux fois plus vite.
Pourquoi ? Parce qu'un homme azerty en vaut deux ! ?
------------------------------
Message: 2
Date: Thu, 25 Jun 2015 22:20:04 +0200
From: Julien ?LIE <[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; format=flowed
Hi Richard,
>>> --- a/tests/innd/artparse-t.c
>>> +++ b/tests/innd/artparse-t.c
>>> @@ -59,6 +59,7 @@ fake_innconf(void)
>>> free(innconf);
>>> }
>>> innconf = xmalloc(sizeof(*innconf));
>>> + memset(innconf, 0, sizeof *innconf);
>>> innconf->logipaddr = false;
>>> innconf->maxartsize = 8 * 1024;
>>> innconf->pathetc = xstrdup("../data/etc");
>>
>> Shouldn't the same memset() line be added after the allocation
>> of innconf in the following files?
>> - tests/overview/api-t.c
>> - tests/overview/overview-t.c
>> - tests/overview/xref-t.c
>> - lib/innconf.c
>
> Wouldn't hurt!
OK, done.
Interestingly, only lib/dbz.c was initializing innconf with 0es:
innconf = xcalloc(1, sizeof(struct innconf));
>> "-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?
--
Julien ?LIE
? Le temps, c'est des sesterces. ? (Coquelus)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 73, Issue 13
*******************************************
