> From: Dr. Stephen Henson [mailto:st...@openssl.org] > Sent: Tuesday, January 28, 2014 10:19 PM > To: openssl-users@openssl.org > > On Tue, Jan 28, 2014, Adam McLaurin wrote: > > > I suspect this will result in a double free bug, as I don't think > memory > > ownership of 'data' is actually passed back to the caller (which is > why > > it's 'const char**'). The error isn't really 'popped' from the queue > - > > the queue just gets some indexes adjusted but the structure itself > seems > > unmodified by ERR_get_error_line_data(). What is still moderately > > unclear is exactly at what point the OpenSSL library goes in and > cleans > > out the error queue. My guess (as I said in my previous email) is > that > > the user should call ERR_clear_error() when the error queue becomes > > empty, to actually go through and clean out the internal structures. > > I'll let the OpenSSL experts clarify that, however. In any case, the > > documentation could definitely be improved in this regard. > > Yes the documention is rather old and could be clearer. > > I had to double check with the source to see what was happening. The > functions > that retrieve errors all end up calling get_error_values in > crypto/err/err.c . > > Errors are stored in a per-thread circular buffer. > > In the case of ERR_get_error_line_data: > > If you don't retrieve the extra error data then it is freed > immediately. > > Otherwise you get an internal pointer into the error queue (which is > why it is > const). The memory will be freed either when you clear the queue > explicitly > with ERR_clear_error() or a new entry is added which overwrites the > internal > extra data pointer. > > Additionally when thread cleanup is performed using > ERR_remove_thread_state() > the whole table for that thread is freed which includes any extra error > data > which hasn't been already freed.
Ugh. Thanks for checking Steve, that's rather different from the understanding I'd built up. I suggest a quick fix to improve the documentation would be simply to delete the sentence "If it has been allocated by OPENSSL_malloc(), *flags&ERR_TXT_MALLOCED is true". At the moment, that appears to be giving a hint that the caller must free it, whereas it's actually an internal detail of no use to the caller and rather dangerous for him to know. If I remember correctly, few (if any) bits of code malloc the string at the moment, so it's not currently a big issue in practice. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
