Libtiff missing on some runs with MSan sanitizer. |
|||||||||
Issue descriptionLibtiff is missing sometimes on swarming bots. Executing rtc_media_unittests fails in: https://chromium-swarm.appspot.com/user/task/3222f8df6b873110 ./rtc_media_unittests: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory However, it executes successfully in: https://chromium-swarm.appspot.com/user/task/32232ca4f9c3e310 maruel: Do you know why this might be? This seems to be only a problem for MSan. In case it matters, these are the GN arguments: dcheck_always_on = true ffmpeg_branding = "Chrome" goma_dir = "/b/c/cipd/goma" is_clang = true is_component_build = false is_debug = false is_msan = true msan_track_origins = 2 rtc_use_h264 = true target_cpu = "x64" use_goma = true use_prebuilt_instrumented_libraries = true
,
Oct 31 2016
Has there been any progress on this?
,
Oct 31 2016
Ryan/Sana, can you confirm all Swarming bots are using reasonably recent images?
,
Oct 31 2016
Wait I don't see libtiff in install-build-deps.sh https://cs.chromium.org/chromium/src/build/install-build-deps.sh?q=install-build-deps.sh&sq=package:chromium&dr Why would this be in the image?
,
Oct 31 2016
I can't find any reference to libtiff from anything but pdfium, especially not in WebRTC. I have no idea why this library would be attempted to be loaded when launching rtc_media_unittests. Is this something related to instrumented libraries for MSan or something along those lines? Adding glider@ for a comment on that.
,
Nov 4 2016
libtiff isn't expected to be in the image (since it's not in install-build-deps.sh). Marking as WAI
,
Nov 7 2016
hinoka: Assuming your answer in #6 was a "yes" to the question in #3: I don't think we can just close this since then don't understand why it happened in the first place. Edward: are we still seeing errors like this or was it a one-off. In the latter case I guess I'd be OK to close this. glider: can you respond to #5?
,
Nov 7 2016
Yes. We're still seeing these errors. Well, were, because the bots are currently offline, but all builds so far have failed because of this.
,
Nov 16 2016
maruel: Ok, this doesn't make any sense. After this CL https://codereview.webrtc.org/2503503002/ where we replaced the command to be run from ../../testing/test_env.py ./test_binary --asan=0 --msan=1 --tsan=0 to ../../testing/test_env.py ../../third_party/gtest-parallel/gtest-parallel ./test_binary -- --asan=0 --msan=1 --tsan=0 the problem went away. The problem is fixed now, but I just thought this is very strange, and maybe you'd like to know. gtest-parallel basically creates a thread to run each test into: https://github.com/google/gtest-parallel/blob/master/gtest-parallel
,
Nov 16 2016
I just noted, you request "os:Linux". This is incorrect, please update your swarming.py trigger site (likely the recipe) to specify the OS version you use, likely os:Ubuntu-14.04, otherwise you'll randomly get a os:Ubuntu-12.04 selected. Please fix this first.
,
Nov 16 2016
Done.
,
Nov 16 2016
Edward, can you point at the CL, then notify here if this problem ever happen on a task that is using os:Ubuntu-14.04 ? I don't have any action item on this issue until then.
,
Nov 18 2016
Closing as wont fix, since we haven't had any problems anymore. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by mar...@chromium.org
, Oct 28 2016