Comment 49 for bug 867424

toolkit/xre/nsAppRunner.cpp:SaveToEnv() intentionally leaks memory because it ends up calling putenv(3) which 'leaks' by design and by specification - this was suppressed for valgrind in bug #793534. But I don't understand why this doesn't trigger the leak sanitizer in the existing code - also there's nothing in these patches that touches nsAppRunner.cpp.

I can't reproduce this locally but I made a couple of wild guesses as to what change could trigger the lsan warning (https://hg.mozilla.org/try/rev/9770e1ff4923 and https://hg.mozilla.org/try/rev/69de1e6095ae ) but the try job still fails - https://treeherder.mozilla.org/#/jobs?repo=try&revision=59094121359b&selectedJob=22442721

If there was an nspr function that used setenv(3) instead of putenv(3) then the strings would be copied inside libc and the existing lsan suppression for libc would cover this.

needinfo'ing mccr8 in case he has any insight into this.