Closed Bug 856687 Opened 11 years ago Closed 11 years ago

Intermittent Android "OSError: [Errno 13] Permission denied" at mozcrash.py line 115 in the check_for_crashes minidump stackwalk call

Categories

(Testing :: Talos, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure, Whiteboard: [mozbase])

This started happening around the end of last week. This is cloned from bug 829690, though I'm not sure what the relationship is between the two.
Callek, any idea why calling the crashreporter binaries would yield oserror: permission denied?  I assume it is the binary is having trouble with permissions, but it could be the pulled stack as well.
No longer depends on: 829690
I would love logging as to what proc we are trying to fire, and any reason we can think of for why its failing in the log itself.

For reference:

[cltbld@foopy87 panda-0695]$ find ./test/tools/breakpad/ -name *stackwalk* -exec ls -l {} \;
-rwx------ 1 cltbld cltbld 1316240 Apr  1 13:33 ./test/tools/breakpad/osx/minidump_stackwalk
-rwx------ 1 cltbld cltbld 1926016 Apr  1 13:33 ./test/tools/breakpad/linux64/minidump_stackwalk
-rwx------ 1 cltbld cltbld 1803072 Apr  1 13:33 ./test/tools/breakpad/linux/minidump_stackwalk
-rwx------ 1 cltbld cltbld 5032443 Apr  1 13:33 ./test/tools/breakpad/win32/minidump_stackwalk.exe

[cltbld@foopy87 panda-0695]$ ls -l ../minidump_stackwalk
lrwxrwxrwx 1 cltbld cltbld 49 Nov 13 12:56 ../minidump_stackwalk -> /builds/tools/breakpad/linux64/minidump_stackwalk

So I'm not sure how we're calling the file here. The line ref'd in almost assuredly not the line I see in m-c: http://mxr.mozilla.org/mozilla-central/source/testing/mozbase/mozcrash/mozcrash/mozcrash.py#115

Also:

[cltbld@foopy87 panda-0695]$ hg clone http://hg.mozilla.org/build/talos tmp
requesting all changes
adding changesets
adding manifests
adding file changes
added 627 changesets with 2990 changes to 1535 files (+1 heads)
updating to branch default
563 files updated, 0 files merged, 0 files removed, 0 files unresolved
[cltbld@foopy87 panda-0695]$ find ./tmp/talos/ -name *stackwalk* -exec ls -l {} \;
-rwxrwxr-x 1 cltbld cltbld 1316240 Apr  1 14:35 ./tmp/talos/breakpad/osx/minidump_stackwalk
-rwxrwxr-x 1 cltbld cltbld 1926016 Apr  1 14:35 ./tmp/talos/breakpad/linux64/minidump_stackwalk
-rwxrwxr-x 1 cltbld cltbld 1316240 Apr  1 14:35 ./tmp/talos/breakpad/osx64/minidump_stackwalk
-rwxrwxr-x 1 cltbld cltbld 1803072 Apr  1 14:35 ./tmp/talos/breakpad/linux/minidump_stackwalk
-rwxrwxr-x 1 cltbld cltbld 5032443 Apr  1 14:35 ./tmp/talos/breakpad/win32/minidump_stackwalk.exe
Joel, any insights/answers re c#4
Flags: needinfo?(jmaher)
I am not sure why this started happening, but I suspect this was a talos deployment late last week.  Most likely it was created with a windows box.  I am working in bug 857394 to remediate this problem.
Flags: needinfo?(jmaher)
Whiteboard: [mozbase]
Could we repack the Talos used on mozilla-beta with the same revision but correct permissions? That seems to be the only place still hitting this.
Flags: needinfo?(jmaher)
here we go, if releng can upload this:
http://people.mozilla.org/~jmaher/taloszips/zips/talos.560806cfa208.zip

to replace the existing one, all the breakpad executables have +x now!
Flags: needinfo?(jmaher)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.