1578951 - 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)

Status: RESOLVED FIXED

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

Description

[ISHIKAWA, Chiaki]

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)
==31965==

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.

TIA

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 2

[Jon Coppeard (:jonco)]

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.

Comment 3

[Jon Coppeard (:jonco)]

Attachment: Bug 1578951 - Mark poisoned zone pointer as defined before checking its contents r?jandem

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a864ed2ae59a
Mark poisoned zone pointer as defined before checking its contents r=jandem

Comment 5

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/a864ed2ae59a

Comment 6

[ISHIKAWA, Chiaki]

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 (!)

Comment 7

[Jon Coppeard (:jonco)]

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

Comment 8

[ISHIKAWA, Chiaki]

You are welcome :-)