Closed Bug 1578951 Opened 3 months ago Closed 2 months ago

Conditional jump or move depends on uninitialised value(s): js::gc::Chunk::allocateArena(JSRuntime*, JS::Zone*, js::gc::AllocKind, js::AutoLockGC const&) (Heap-inl.h:18)


(Core :: JavaScript: GC, defect, P3)




Tracking Status
firefox71 --- fixed


(Reporter: ishikawa, Assigned: jonco)





(1 file)

This is with M-C and C-C updated a couple of days ago.

Found with valgrind:

With valgrind, I found the problem under linux AMD64 when I run |make mozmill| testsuite with fully debug version of TB, but this problem will be universal across platforms.
(OK, I am using GCC 8 if it matters.)

==31965== Conditional jump or move depends on uninitialised value(s)
==31965== at 0xE823EDE: js::gc::Chunk::allocateArena(JSRuntime*, JS::Zone*, js::gc::AllocKind, js::AutoLockGC const&) (Heap-inl.h:18)
==31965== by 0xE82427F: js::gc::GCRuntime::allocateArena(js::gc::Chunk*, JS::Zone*, js::gc::AllocKind, js::gc::ShouldCheckThresholds, js::AutoLockGC const&) (Allocator.cpp:602)
==31965== by 0xE824603: js::gc::ArenaLists::refillFreeListAndAllocate(js::gc::FreeLists&, js::gc::AllocKind, js::gc::ShouldCheckThresholds) (Allocator.cpp:513)
==31965== by 0xE8247C9: js::gc::GCRuntime::refillFreeListFromMainThread(JSContext*, js::gc::AllocKind) (Allocator.cpp:449)
==31965== by 0xE8248D7: js::gc::GCRuntime::refillFreeListFromAnyThread(JSContext*, js::gc::AllocKind) (Allocator.cpp:436)
==31965== by 0xE8402FF: js::NormalAtom* js::gc::GCRuntime::tryNewTenuredThing<js::NormalAtom, (js::AllowGC)0>(JSContext*, js::gc::AllocKind, unsigned long) (Allocator.cpp:275)
==31965== by 0xE840358: js::NormalAtom* js::Allocate<js::NormalAtom, (js::AllowGC)0>(JSContext*) (Allocator.cpp:255)
==31965== by 0xE4630DF: js::StaticStrings::init(JSContext*) (StringType-inl.h:324)
==31965== by 0xE28CF4B: JSRuntime::initializeAtoms(JSContext*) (JSAtom.cpp:245)
==31965== by 0xE580739: JS::InitSelfHostedCode(JSContext*) (jsapi.cpp:423)
==31965== by 0x9DFD390: nsXPConnect::InitStatics() (nsXPConnect.cpp:141)
==31965== by 0x9DBCBF2: xpcModuleCtor() (XPCModule.cpp:11)
==31965== by 0xD102E9A: nsLayoutModuleInitialize() (nsLayoutModule.cpp:107)
==31965== by 0x917B3ED: nsComponentManagerImpl::Init() (nsComponentManager.cpp:493)
==31965== by 0x91D8BF3: NS_InitXPCOM (XPCOMInit.cpp:445)
==31965== by 0xDF5296A: ScopedXPCOMStartup::Initialize() (nsAppRunner.cpp:1279)
==31965== by 0xDF5F548: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (nsAppRunner.cpp:4707)
==31965== by 0xDF5FC56: XRE_main(int, char**, mozilla::BootstrapConfig const&) (nsAppRunner.cpp:4792)
==31965== by 0xDF61B12: mozilla::BootstrapImpl::XRE_main(int, char**, mozilla::BootstrapConfig const&) (Bootstrap.cpp:45)
==31965== by 0x11261A: do_main(int, char**, char**) (nsMailApp.cpp:210)
==31965== by 0x1126C8: main (nsMailApp.cpp:285)

I noticed possibly related two errors:
Bug 1039379
Intermittent browser_console_optimized_out_vars.js | application crashed [@ js::gc::Chunk::allocateArena(JS::Zone*, js::gc::AllocKind)]

Bug 1033441
Intermittent browser_console_private_browsing.js | application crashed [@ js::gc::Chunk::allocateArena(JS::Zone*, js::gc::AllocKind)]

If a function reads uninitialized value, then it can possibly contain bogus value that could result in crash later.


Component: Memory Allocator → JavaScript: GC

The priority flag is not set for this bug.
:jonco, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jcoppeard)

We poison Arena::zone on free and mark its contents as undefined, but later asserts that it has been poisoned. valgrind flags this as an error.

Flags: needinfo?(jcoppeard)
Priority: -- → P3
Regressed by: 1552180
Assignee: nobody → jcoppeard

Marking Arena::zone as defined before the assertion should fix this. Looking at this again, I should have make this MakeNoAccess in the first place, so I did that too.

Pushed by
Mark poisoned zone pointer as defined before checking its contents r=jandem
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Thank you for the fix. I ran valgrind for the last few weeks.
This warning has not appeared during |make mozmill| test running C-C TB under valgrind since the fix was applied (!)

(In reply to ISHIKAWA, Chiaki from comment #6)
Great, thanks for verifying!

You are welcome :-)

You need to log in before you can comment on or make changes to this bug.