Closed Bug 1279105 Opened 8 years ago Closed 8 years ago

AddressSanitizer: 72 byte(s) leaked in 1 allocation(s) #1 0x7f9eaa9a19a1 in error_get_my_stack

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: glandium, Assigned: glandium)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

This happens when switching to clang 3.8 for ASAN builds (instead of 3.5 currently): 
https://treeherder.mozilla.org/logviewer.html#?job_id=22157690&repo=try#L2940

 23:35:20     INFO -  PROCESS | 17882 | =================================================================
 23:35:20     INFO -  PROCESS | 17882 | ==17900==ERROR: LeakSanitizer: detected memory leaks
 23:35:20     INFO -  PROCESS | 17882 | Direct leak of 72 byte(s) in 1 object(s) allocated from:
 23:35:20     INFO -  PROCESS | 17882 |     #0 0x4b12a4 in calloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
 23:35:20     INFO -  PROCESS | 17882 |     #1 0x7f9eaa9a19a1 in error_get_my_stack /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/base/error.c:109:17
 23:35:20     INFO -  PROCESS | 17882 |     #2 0x7f9eaa9a1cf8 in nss_ClearErrorStack /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/base/error.c:245:23
 23:35:20     INFO -  PROCESS | 17882 |     #3 0x7f9eaa9a04a8 in NSSArena_Create /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/base/arena.c:329:5
 23:35:20     INFO -  PROCESS | 17882 |     #4 0x7f9eaa98196e in NSSTrustDomain_Create /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/pki/trustdomain.c:34:13
 23:35:20     INFO -  PROCESS | 17882 |     #5 0x7f9eaa98d0a9 in STAN_LoadDefaultNSS3TrustDomain /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/pki/pki3hack.c:118:10
 23:35:20     INFO -  PROCESS | 17882 |     #6 0x7f9eaa8b2423 in nss_Init /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/nss/nssinit.c:655:6
 23:35:20     INFO -  PROCESS | 17882 |     #7 0x7f9eaa8b348f in NSS_Initialize /builds/slave/try-l64-asan-00000000000000000/build/src/security/nss/lib/nss/nssinit.c:812:12
 23:35:20     INFO -  PROCESS | 17882 |     #8 0x4e6d9b in NSSInitCryptoContext /builds/slave/try-l64-asan-00000000000000000/build/src/modules/libmar/sign/mar_sign.c:37:22
 23:35:20     INFO -  PROCESS | 17882 |     #9 0x4e6d9b in mar_repackage_and_sign /builds/slave/try-l64-asan-00000000000000000/build/src/modules/libmar/sign/mar_sign.c:853
 23:35:20     INFO -  PROCESS | 17882 |     #10 0x4deb08 in main /builds/slave/try-l64-asan-00000000000000000/build/src/modules/libmar/tool/mar.c:412:12
 23:35:20     INFO -  PROCESS | 17882 |     #11 0x7f9ea8acd76c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
 23:35:20     INFO -  PROCESS | 17882 | SUMMARY: AddressSanitizer: 72 byte(s) leaked in 1 allocation(s).
23:35:20 WARNING - TEST-UNEXPECTED-FAIL | modules/libmar/tests/unit/test_sign_verify.js | signMAR - [signMAR : 44] 1 == 0

This may or may not be mar's fault, I haven't dug yet.
Blocks: 1278718
This looks like a benign leak to me.

In error.c:109 (error_get_my_stack) we return |new_stack = PR_Calloc(1, new_bytes);| which we return to nss_ClearErrorStack

    error_stack *es = error_get_my_stack();
    if ((error_stack *)NULL == es) {
        /* Oh, well. */
        return;
    }

    es->header.count = 0;
    es->stack[0] = 0;
    return;

We have to free |es| here.
But then I'm not sure if this function actually does anything useful. error_get_my_stack copies the stack before returning it (nsslibc_memcpy(new_stack, rv, rv->header.space)). So if I'm not missing anything, nss_ClearErrorStack has no observable effect.
The important part is in error_get_my_stack, which uses PR_SetThreadPrivate.

It would seem that nss_DestroyErrorStack is never called (or NSS_Shutdown, for that matter, but shouldn't there be more leaks detected if that were the case?).
modules/libmar/sign/mar_sign.c never calls NSS_Shutdown...
Assignee: nobody → mh+mozilla
Component: Libraries → Application Update
Product: NSS → Toolkit
Version: trunk → unspecified
Comment on attachment 8761690 [details]
Bug 1279105 - Properly shutdown NSS after NSSInitCryptoContext was called.

https://reviewboard.mozilla.org/r/58788/#review55740

I'm fine with this but I'd like to have Brian Smith (:briansmith) also look at this so clearing review.
Attachment #8761690 - Flags: review?(robert.strong.bugs)
Comment on attachment 8761690 [details]
Bug 1279105 - Properly shutdown NSS after NSSInitCryptoContext was called.

Brian, could you verify that calling NSS_Shutdown is ok for the app update use case? Thanks.
Attachment #8761690 - Flags: review?(brian)
Attachment #8761690 - Flags: review?(brian) → review?(robert.strong.bugs)
Comment on attachment 8761690 [details]
Bug 1279105 - Properly shutdown NSS after NSSInitCryptoContext was called.

Talked with Brian Smith and he doesn't recall any reason for this. I'll review this in the near future
https://reviewboard.mozilla.org/r/58788/#review56246

::: modules/libmar/sign/mar_sign.c:1156
(Diff revision 1)
>      }
>  
>      SECITEM_FreeItem(&secItems[k], PR_FALSE);
>    }
>  
> +  (void)NSS_Shutdown();

Pardon the unsolicited comment, but checking the return value from NSS_Shutdown can indicate when NSS resources (e.g. CERTCertificates) haven't been released. I'm not sure that's a particular concern in this code, but it can help find bugs.
Attachment #8761690 - Flags: review?(robert.strong.bugs) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dda36986f0ce
Properly shutdown NSS after NSSInitCryptoContext was called. r=rstrong
https://hg.mozilla.org/mozilla-central/rev/dda36986f0ce
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: