Closed Bug 970164 Opened 10 years ago Closed 10 years ago

TEST-UNEXPECTED-FAIL | valgrind-test | Syscall param unlink(pathname) points to unaddressable byte(s) at unlink / ffi_call_unix / ffi_call / js::ctypes::FunctionType::Call on bld-linux64-ix-* slaves

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task)

Product:
Infrastructure & Operations Graveyard
Component:
CIDuty
Platform:
x86_64
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

Details

(Keywords: intermittent-failure) 

Sucks to get ix slaves for your Valgrind run:

https://tbpl.mozilla.org/?showall=1&tree=Mozilla-Inbound&rev=8a36e37f46ed got a run on bld-linux64-ix-030 which failed this way, and a retrigger on bld-linux64-ix-036 which failed the same way; the push before it had been green on bld-centos6-hp-013 and my retrigger there on bld-centos6-hp-015 was green, so I backed out 8a36e37f46ed, and my backout was green on bld-centos6-hp-013.

After five green pushes on various centos-hp and ec2 slaves, bld-linux64-ix-036 had a red run, which I attributed to the backout having required a clobber, despite the extreme unlikeliness of that.

Four pushes later, https://tbpl.mozilla.org/php/getParsedLog.php?id=34396034&tree=Mozilla-Inbound, bld-linux64-ix-035 has the same failure, despite not having done an inbound Valgrind run since January 27th, and despite clobbering.

No idea how this can be the case, but this particular Valgrind failure is bld-linux64-ix-*-only.
Keywords: intermittent-failure
Passing a garbage string to unlink(), perhaps?
Reproduced locally, by accident when looking for something else.  Looks
like someone somewhere is doing unlink(NULL).

Syscall param unlink(pathname) points to unaddressable byte(s)
   at 0x349F0E60C7: unlink (syscall-template.S:82)
   by 0x7A10033: ffi_call_unix64 (in /home/sewardj/MOZ/MC-12-02-2014/ff-opt-linux64/toolkit/library/libxul.so)
   by 0x7A0F989: ffi_call (ffi64.c:485)
   by 0x768AC35: js::ctypes::FunctionType::Call(JSContext*, unsigned int, JS::Value*) (CTypes.cpp:5854)
   by 0x797E76B: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:230)
   by 0x789E2FA: js_fun_apply(JSContext*, unsigned int, JS::Value*) (jsfun.cpp:1069)
   by 0x797E5D9: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:230)
   by 0x797A595: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2608)
   by 0x797DDA1: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:423)
   by 0x797E538: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:495)
   by 0x789E2FA: js_fun_apply(JSContext*, unsigned int, JS::Value*) (jsfun.cpp:1069)
   by 0x797E5D9: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:230)
 Address 0x0 is not stack'd, malloc'd or (recently) free'd
> Looks like someone somewhere is doing unlink(NULL).

Well, yes :) I had a quick look at the code in the stack, and it's extremely generic call-a-function code -- the function and its argument are both arguments passed down from above. If you can catch it in a debugger and do some inspection to see which JS function is involved, that would be helpful.
Closing bugs where TBPLbot has previously commented, but have now not been modified for >3 months & do not contain the whiteboard strings for disabled/annotated tests or use the keyword leave-open. Filter on: mass-intermittent-bug-closure-2014-07
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.