Closed Bug 1606007 Opened 4 years ago Closed 4 years ago

Valgrind builds fail with rustc 1.40: Syscall param statx(file_name) points to unaddressable byte(s) at ...

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox74 fixed)

RESOLVED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: chmanchester, Assigned: glandium)

References

Details

Attachments

(1 file)

0:40.52 TEST-UNEXPECTED-FAIL | valgrind-test | Syscall param statx(file_name) points to unaddressable byte(s) at syscall / std::sys::unix::fs::try_statx / std::sys::unix::fs::stat / rkv::env::Rkv::new
0:40.52 ==8512== Syscall param statx(file_name) points to unaddressable byte(s)
0:40.52 ==8512==    at 0x5CD6829: syscall+25 (syscall.S:39)
0:40.52 ==8512==    by 0x141EB3DB: std::sys::unix::fs::try_statx+75 (weak.rs:94)
0:40.52 ==8512==    by 0x141ECD53: std::sys::unix::fs::stat+115 (fs.rs:995)
0:40.52 ==8512==    by 0x141BA838: rkv::env::Rkv::new+40 (src/libstd/fs.rs:1553)
0:40.52 ==8512==    by 0x147A4684: xulstore::statics::get_database+1156 (statics.rs:50)
0:40.52 ==8512==    by 0x1479F755: xulstore::statics::cache_data+37 (statics.rs:176)
0:40.52 ==8512==    by 0x1479F469: std::sync::once::Once::call_once::{{closure}}+57 (statics.rs:43)
0:40.52 ==8512==    by 0x141F1DFF: std::sync::once::Once::call_inner+319 (once.rs:391)
0:40.52 ==8512==    by 0x147B2729: xulstore::get_value+1369 (once.rs:224)
0:40.52 ==8512==    by 0x1479D768: xulstore::ffi::XULStoreService::allocate::GetValue+56 (ffi.rs:88)
0:40.52 ==8512==    by 0xFA0D201: ??? (xptcinvoke_asm_x86_64_unix.S:106)
0:40.52 ==8512==    by 0x102E2F75: Invoke (js/xpconnect/src/XPCWrappedNative.cpp:1643)
0:40.52 ==8512==    by 0x102E2F75: Call (js/xpconnect/src/XPCWrappedNative.cpp:1184)
0:40.52 ==8512==    by 0x102E2F75: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)+3797 (js/xpconnect/src/XPCWrappedNative.cpp:1150)
0:40.52 ==8512==    by 0x102E4538: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)+616 (js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946)
0:40.52 ==8512==    by 0x133B45E7: CallJSNative (js/src/vm/Interpreter.cpp:452)
0:40.52 ==8512==    by 0x133B45E7: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)+1031 (js/src/vm/Interpreter.cpp:544)
0:40.52 ==8512==    by 0x133AB9EF: CallFromStack (js/src/vm/Interpreter.cpp:612)
0:40.52 ==8512==    by 0x133AB9EF: Interpret(JSContext*, js::RunState&)+54351 (js/src/vm/Interpreter.cpp:3042)
0:40.52 ==8512==    by 0x1339E38F: js::RunScript(JSContext*, js::RunState&)+287 (js/src/vm/Interpreter.cpp:424)
0:40.52 ==8512==    by 0x133B5C57: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::AbstractFramePtr, JS::Value*)+263 (js/src/vm/Interpreter.cpp:801)
0:40.52 ==8512==    by 0x133EC905: ExecuteInExtensibleLexicalEnvironment(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>)+277 (js/src/builtin/Eval.cpp:487)
0:40.52 ==8512==    by 0x133ECC07: js::ExecuteInJSMEnvironment(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::Handle<JS::StackGCVector<JSObject*, js::TempAllocPolicy> >)+263 (js/src/builtin/Eval.cpp:596)
0:40.52 ==8512==    by 0x133ECAB6: js::ExecuteInJSMEnvironment(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>)+102 (js/src/builtin/Eval.cpp:549)
0:40.52 ==8512==    by 0x10295441: mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>)+1425 (js/xpconnect/loader/mozJSComponentLoader.cpp:936)
0:40.52 ==8512==    by 0x10297C17: mozJSComponentLoader::Import(JSContext*, nsTSubstring<char> const&, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSObject*>, bool)+2231 (js/xpconnect/loader/mozJSComponentLoader.cpp:1353)
0:40.52 ==8512==    by 0xF9DAA43: mozilla::xpcom::ConstructJSMComponent(nsTSubstring<char> const&, char const*, nsISupports**)+211 (StaticComponents.cpp:1610)
0:40.52 ==8512==    by 0xF9D99E1: mozilla::xpcom::CreateInstanceImpl(mozilla::xpcom::ModuleID, nsISupports*, nsID const&, void**)+31505 (StaticComponents.cpp:0)
0:40.52 ==8512==    by 0xF9E2D7C: CreateInstance (xpcom/components/nsComponentManager.cpp:219)
0:40.52 ==8512==    by 0xF9E2D7C: nsComponentManagerImpl::GetServiceLocked((anonymous namespace)::MutexLock&, (anonymous namespace)::EntryWrapper&, nsID const&, void**)+636 (xpcom/components/nsComponentManager.cpp:1372)
0:40.52 ==8512==    by 0xF9DF390: nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**)+304 (xpcom/components/nsComponentManager.cpp:1559)
0:40.52 ==8512==    by 0xF9E53C6: CallGetService (xpcom/components/nsComponentManagerUtils.cpp:61)
0:40.52 ==8512==    by 0xF9E53C6: nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const+38 (xpcom/components/nsComponentManagerUtils.cpp:253)
0:40.52 ==8512==    by 0xF97600A: nsCOMPtr_base::assign_from_gs_contractid_with_error(nsGetServiceByContractIDWithError const&, nsID const&)+42 (xpcom/base/nsCOMPtr.cpp:91)
0:40.52 ==8512==    by 0x132E7A08: operator= (dist/include/nsCOMPtr.h:1037)
0:40.52 ==8512==    by 0x132E7A08: nsAppStartupNotifier::NotifyObservers(char const*)+536 (toolkit/xre/nsAppStartupNotifier.cpp:42)
0:40.52 ==8512==    by 0x132E3F17: XREMain::XRE_mainRun()+1463 (toolkit/xre/nsAppRunner.cpp:4406)
0:40.52 ==8512==    by 0x132E4BE7: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&)+1239 (toolkit/xre/nsAppRunner.cpp:4737)
0:40.52 ==8512==    by 0x132E512E: XRE_main(int, char**, mozilla::BootstrapConfig const&)+158 (toolkit/xre/nsAppRunner.cpp:4818)
0:40.52 ==8512==    by 0x117089: do_main (browser/app/nsBrowserApp.cpp:217)
0:40.52 ==8512==    by 0x117089: main+1001 (browser/app/nsBrowserApp.cpp:339)
0:40.52 ==8512==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
0:40.52 ==8512==

Per https://github.com/rust-lang/rust/blob/3ac40b69c75929dac5115b6a49eb4f1ecc352416/src/libstd/sys/unix/fs.rs#L142 this appears intentional.

Julian, does this seem like the sort of thing that would be safe to add a suppression for?

Flags: needinfo?(jseward)

Hi Chris. tl;dr is that this will be "fixed" in the next release of valgrind, and the fix is already
in the V trunk sources. I expect there will be a new automation V snapshot made in the next
couple of weeks. The report is due to rustlib's somewhat dubious use of the statx system call
in such a way as to quickly check whether it is supported, by passing two NULL pointers to it.

Flags: needinfo?(jseward)

Thanks for the info, Julian! Is there a bug tracking this update? Would it seem reasonable to add a suppression in the interim?

The added hacks are derived from what was used in bug 1479055.

Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/3c5143f5d3f9
Upgrade valgrind to current git trunk. r=froydnj
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: