Closed Bug 962921 Opened 10 years ago Closed 9 years ago

Intermittent TEST-UNEXPECTED-FAIL | valgrind-test | non-zero exit code, preceded by ERROR SUMMARY with lots of errors, due to lots of JS-related leaks

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: n.nethercote, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure) 

https://tbpl.mozilla.org/php/getParsedLog.php?id=33396581&tree=Mozilla-Inbound failed like this:

> ==pid== ERROR SUMMARY: 101 errors from 101 contexts (suppressed: 71 from 65)
> TEST-UNEXPECTED-FAIL | valgrind-test | non-zero exit code

In this run we leaked tons of JS-related stuff in the main process. I suspect we somehow shutdown without doing a final GC/CC, despite the setting of the XPCOM_CC_RUN_DURING_SHUTDOWN env variable. Or maybe the final GC/CC somehow didn't clean everything up properly.

Here are the topmost non-allocation frames from the distinct leaks.

> JSScript::partiallyInit(js::ExclusiveContext*, JS::Handle<JSScript*>, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) (Utility.h:150)
>
> JSScript::makeTypes(JSContext*) (Utility.h:150)
>
> AllocateSlots(js::ThreadSafeContext*, JSObject*, unsigned int) (Utility.h:144)
>
> js::NativeIterator::allocateIterator(JSContext*, unsigned int, JS::AutoIdVector const&) (Utility.h:144)
>
> HashChildren(js::Shape*, js::Shape*) (Utility.h:144)
>
> ReallocateSlots(js::ThreadSafeContext*, JSObject*, js::HeapSlot*, unsigned int, unsigned int) (Utility.h:162)
>
> js::Shape::hashify(js::ThreadSafeContext*, js::Shape*) (Utility.h:144)
>
> js::GlobalObject::initFunctionAndObjectClasses(JSContext*) (Utility.h:144)
>
> HashChildren(js::Shape*, js::Shape*) (Utility.h:144)
>
> js::frontend::CompileScript(js::ExclusiveContext*, js::LifoAlloc*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::ReadOnlyCompileOptions const&, char16_t const*, unsigned long, JSString*, unsigned int, js::SourceCompressionTask*) (Utility.h:144)
>
> js::RegExpStatics::create(JSContext*, js::GlobalObject*) (Utility.h:144)
>
> XPCWrappedNative::WrapNewGlobal(xpcObjectHelper&, nsIPrincipal*, bool, JS::CompartmentOptions&, XPCWrappedNative**) (mozalloc.h:201)
>
> JSObject::create(js::ExclusiveContext*, js::gc::AllocKind, js::gc::InitialHeap, JS::Handle<js::Shape*>, JS::Handle<js::types::TypeObject*>, js::HeapSlot*) (jsobjinlines.h:506)
>
> xpc::CreateGlobalObject(JSContext*, JSClass const*, nsIPrincipal*, JS::CompartmentOptions&) (mozalloc.h:201)
(In reply to TBPL Robot from comment #1)
> edmorley
> https://tbpl.mozilla.org/php/getParsedLog.php?id=36278274&tree=Mozilla-
> Inbound
> Linux x86-64 mozilla-inbound valgrind on 2014-03-17 10:02:32
> revision: bf236376056c
> slave: bld-linux64-spot-427
> 
> TEST-UNEXPECTED-FAIL | valgrind-test | non-zero exit code from Valgrind

This one doesn't match this bug's title -- there weren't lots of leak warnings preceding the "non-zero exit code" line. In fact, there weren't any warnings. However, there was this, which I haven't seen before:

> Error: cannot open display: :2

This doesn't come from Valgrind. I guess it comes from Firefox, or maybe the X server.
Looked like ye olde bug 797242 to me.
(In reply to TBPL Robot from comment #4)
> Tomcat
> https://tbpl.mozilla.org/php/getParsedLog.php?id=40542259&tree=Mozilla-
> Inbound
> Linux x86-64 mozilla-inbound valgrind on 2014-05-28 05:50:54
> revision: a32b415a167a
> slave: bld-linux64-spot-394
> 
> TEST-UNEXPECTED-FAIL | valgrind-test | non-zero exit code from Valgrind

Same story as comment 2.
Inactive; closing (see bug 1180138).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.