> On Jul 31, 2018, at 4:59 AM, Matt Caswell wrote:
>
> To be clear I can only think of one leak that we have at process exit
> (well technically its two instances of the same thing). And that leak is
> not the result of a *mistake*. It is a deliberate design decision to
> workaround around a
On 31/07/2018 01:10, Jordan Brown wrote:
On 7/30/2018 12:27 PM, Viktor Dukhovni wrote:
The only time such "leaks" come into play is process exit and library
unload.
Process exit is not the only time that libraries get unloaded. I
don't happen to remember any details, but I know we've had
On 30/07/18 19:08, Marty G wrote:
> On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote:
>
>> > I never thought I'd see the day that someone would have to defend
>> not leaking memory in pivotal security code like openssl however
>>
>>
>>
>> To be accurate, it was a couple of people
On 7/30/2018 11:12 AM, Michael Wojcik wrote:
> As for Jordan's objection: If you don't know the source of your
> "leaks", then I can't say I'm particularly impressed with a
> zero-"leak" policy. That amounts to "let's burn a lot of cycles during
> process termination, rather than understand what
On 7/30/2018 12:27 PM, Viktor Dukhovni wrote:
> The only time such "leaks" come into play is process exit and library
> unload.
Process exit is not the only time that libraries get unloaded. I don't
happen to remember any details, but I know we've had problems with
libraries that got unloaded
> On Jul 30, 2018, at 3:43 PM, Marty G wrote:
>
>> Spending valuable cycles to eliminate these is not the most productive
>> use of our time.
I meant "developer cycles", not CPU cycles.
> How often does a process exit? Only once.
--
Viktor.
--
openssl-users mailing list
To
On 07/30/2018 03:27 PM, Viktor Dukhovni wrote:
The only time such "leaks" come into play is process exit and library
unload. My advice is to not unload the library and to accept the
fact that a small fixed amount of memory might not be deallocated
at exit. Typically, even "valgrind" will not
> On Jul 30, 2018, at 3:00 PM, Marty G wrote:
>
> Of course I applaud the team's memleak testing! How could my post be
> interpreted otherwise? I wasn't trying to single anyone out, just the
> general idea that any memory leak is of little concern when the implications
> of the leak
On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote:
* So why not just have a rule "don't litter"
Have you looked at, say, the memleak testing we do?
Thanks for the two cents.
Of course I applaud the team's memleak testing! How could my post be
interpreted otherwise? I wasn't
* So why not just have a rule "don't litter"
Have you looked at, say, the memleak testing we do?
Thanks for the two cents.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Salz, Rich via openssl-users
> Sent: Monday, July 30, 2018 11:28
> > I never thought I'd see the day that someone would have to defend not
> > leaking memory
> > in pivotal security code like openssl however
> To
On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote:
> I never thought I'd see the day that someone would have to defend
not leaking memory in pivotal security code like openssl however
To be accurate, it was a couple of people saying that memory leaks *on
process exit* aren’t be a
> I never thought I'd see the day that someone would have to defend not leaking
> memory in pivotal security code like openssl however
To be accurate, it was a couple of people saying that memory leaks *on process
exit* aren’t be a big deal.
--
openssl-users mailing list
To unsubscribe:
On 07/30/2018 12:52 PM, Jordan Brown wrote:
Because a zero-leaks policy is a lot easier to manage than having to
make a judgement call on each leak whether or not it's important, and
having to filter out "unimportant" leaks when you're trying to find
out whether you've introduced any
On 7/30/2018 7:18 AM, Michael Wojcik wrote:
> I don't know why people worry about singleton memory "leaks". If the
> leak isn't growing over the lifetime of the process, it's not causing
> any trouble. I've seen some teams obsessing about getting clean
> reports from dynamic-analysis tools like
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Monday, July 30, 2018 08:02
>
> My recommendation is never unload a library once loaded.
I agree, at least in most cases.
I don't know why people worry about singleton memory "leaks". If the
> On Jul 30, 2018, at 8:26 AM, Graham Leggett wrote:
>
> Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq,
> libldap, etc if we know for sure that openssl < 1.1.0 is linked to them?
My recommendation is never unload a library once loaded.
I don't see the point,
On 24 Jul 2018, at 18:06, Viktor Dukhovni wrote:
>> Or is it correct in v1.1.0 and above to just not initialise anything at all,
>> not clean anything up at all, and expect openssl to “do the right thing”
>> when mod_ssl is unloaded?
>
> Yes. And *especially* when the code that depends on
> On Jul 24, 2018, at 7:40 AM, Graham Leggett wrote:
>
> Or is it correct in v1.1.0 and above to just not initialise anything at all,
> not clean anything up at all, and expect openssl to “do the right thing” when
> mod_ssl is unloaded?
Yes. And *especially* when the code that depends on
On 24 Jul 2018, at 12:15, Graham Leggett wrote:
> Over at httpd we’re struggling with crashes and instability caused by
> attempts by various independent libraries we link to, all of which in turn
> link to openssl, initialising openssl multiple times. In turn these separate
> libraries might
20 matches
Mail list logo
