1032632 - symbolstore.py should use exit status to signal failure

Status: NEW

(Firefox Build System :: General, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

eg, in an Android 31.0b6 build

2014-06-30 22:40:43: dump_symbols.cc:788: INFO: LoadSymbols: SUCCESS dist/bin/libxul.so
/builds/slave/rel-m-beta-and_bld-00000000000/build/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy: /lib64/libz.so.1: no version information available (required by /builds/slave/rel-m-beta-and_bld-00000000000/build/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy)
/builds/slave/rel-m-beta-and_bld-00000000000/build/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy:dist/bin/libxul.so.dbg[.debug_info]: No space left on device
/builds/slave/rel-m-beta-and_bld-00000000000/build/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy:dist/bin/libxul.so.dbg: No space left on device
echo packing symbols
packing symbols
dist/bin/nsinstall -D dist/

Should have stopped when it hit the full disk, rather than continuing down the make target at
 http://mxr.mozilla.org/mozilla-central/source/Makefile.in#216

Full log: http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/31.0b6-candidates/build2/logs/release-mozilla-beta-android_build-bm84-build1-build29.txt.gz

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

I should say that buildbot detects the failure and doesn't run any more steps, but the buildsymbols target shouldn't go on to create and upload the zip when symbol processing has failed.

Comment 2

[(not currently active) Ted Mielczarek]

symbolstore.py does exit with an error code in most situations, but we're not treating errors in objcopy as an error:
http://hg.mozilla.org/mozilla-central/annotate/75f66f8cb99f/toolkit/crashreporter/tools/symbolstore.py#l736

It looks like we've never treated the result of objcopy as fatal (since this was implemented back in bug 420474), but I can't find any reasoning.