> What if the best solution is to abort the operation requesting the big
> chunk of unavailable memory? We don't have any significant cache in
> this process to dump, and it wouldn't have helped for long anyway.
That should be handled in the code that deals with requesting big chunks of
memory. H
On Thu, Mar 5, 2009 at 6:41 PM, David Schwartz wrote:
>> --- crypto\pkcs12\p12_crt.c Wed Mar 4 13:37:26 2009
>>+++ crypto\pkcs12\p12_crt.c Wed Mar 4 12:44:40 2009
>>@@ -168,7 +168,8 @@ PKCS12 *PKCS12_create(char *pass, char *
>>sk_PKCS12_SAFEBAG_pop_free(bags, PKCS12_SAFEBAG_free);
>>
Oh, one more thing. This is a very common type of error. It's very hard
to test all possible out-of-memory paths. Worse, leaks in the error paths is
common (your submitted fix even had one) making it hard to recover from an
out-of-memory condition.
If you are trying to code rel
> --- crypto\pkcs12\p12_crt.c � Wed Mar �4 13:37:26 2009
>+++ crypto\pkcs12\p12_crt.c � �Wed Mar �4 12:44:40 2009
>@@ -168,7 +168,8 @@ PKCS12 *PKCS12_create(char *pass, char *
>�� � � �sk_PKCS12_SAFEBAG_pop_free(bags, PKCS12_SAFEBAG_free);
>�� � � �bags = NULL;
>
>- � � � p12 = PKCS12_add_safes(s
