Closed Bug 1663451 Opened 4 years ago Closed 3 years ago

"fix-stacks: error: failed to read symbols file", no stacktrace

Categories

(Toolkit :: Crash Reporting, defect, P2)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
87 Branch
Tracking Flags:
Tracking Status
firefox87 --- fixed

People

(Reporter: mbrodesser-Igalia, Assigned: gsvelto)

References

(
URL
)

Details

Attachments

(1 file)

Bug 1663451 - Import a new version of fix-stacks with proper fallback to native debuginfo support when breakpad symbols are missing r=KrisWright
48 bytes, text/x-phabricator-request
Details | Review

./mach mochitest --keep-open=false --setpref="fission.sessionHistoryInParent=true" --enable-xorigin-tests --enable-fission --debugger=rr dom/html/test/forms/test_input_hasBeenTypePassword_navigation.html yields:

[...]

 2:20.59 GECKO(8240) Navigated to a new document
 2:20.68 GECKO(8240) Assertion failure: mRawPtr != nullptr (You can't dereference a NULL nsCOMPtr with operator->().), at /home/mirko/src/firefox/gecko2/xpcom/base/nsCOMPtr.h:872
Initializing stack-fixing for the first stack frame, this may take a while...
fix-stacks: error: failed to read symbols file `/home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/crashreporter-symbols/libxul.so/9B344440F4A77A4D508344981F83A0820/libxul.so.sym` for `/home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/bin/libxul.so`
fix-stacks: note: this is expected and harmless for system libraries on debug automation runs
fix-stacks: No such file or directory (os error 2)
 2:21.49 GECKO(8240) #01: ??? [/home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/bin/libxul.so + 0xf9f54c4]
 2:21.49 GECKO(8240) #02: ??? [/home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/bin/libxul.so + 0x12af6d99]

[...]

Expected: a stacktrace including debug symbols (method names).

Should we be falling back to reading symbols directly from the shared libraries if we can't find the breakpad symbols? Or is it expected behavior that people should be building the breakpad symbols always?

Flags: needinfo?(n.nethercote)

The test harness will tell fix-stacks to use Breakpad symbols if they are present, which is always the case on CI but not the usual for local builds unless you've run mach buildsymbols. Failing that, the test harness will tell fix-stacks to use native debug info. The logic for this is here, and for mochitests it is invoked from here.

Mirko, did you build symbols with mach buildsymbols? Presumably. But for some reason there is no libxul.so.sym in the place where fix-stacks expects it. Is there a libxul.so.sym somewhere else in the objdir, perhaps under a different UUID? glandium recently changed how fix-stacks computes the UUID (fix-stacks change, m-c update), it might be related to that.

Flags: needinfo?(n.nethercote) → needinfo?(mbrodesser)

(In reply to Nicholas Nethercote [:njn] from comment #2)

The test harness will tell fix-stacks to use Breakpad symbols if they are present, which is always the case on CI but not the usual for local builds unless you've run mach buildsymbols.

I wasn't aware of this, thanks for the context.

Failing that, the test harness will tell fix-stacks to use native debug info. The logic for this is here, and for mochitests it is invoked from here.

Mirko, did you build symbols with mach buildsymbols? Presumably.

I didn't (because I wasn't aware of it), but I've just executed that and also with that, the symbols aren't shown.

But for some reason there is no libxul.so.sym in the place where fix-stacks expects it. Is there a libxul.so.sym somewhere else in the objdir, perhaps under a different UUID?

There's one at "./obj-x86_64-pc-linux-gnu-debug/dist/crashreporter-symbols/libxul.so/7FBE15CCD52645B07F06541D20FF94EF0/libxul.so.sym".

glandium recently changed how fix-stacks computes the UUID (fix-stacks change, m-c update), it might be related to that.

Flags: needinfo?(mbrodesser)

Mirko: I'm surprised that breakpad symbols are present if you didn't run mach buildsymbols. A possible workaround is to remove the crashreporter-symbols directory in your objdir and then see if the native debug info is used as expected.

glandium: this is the error (from comment 0):

fix-stacks: error: failed to read symbols file /home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/crashreporter-symbols/libxul.so/9B344440F4A77A4D508344981F83A0820/libxul.so.sym for /home/mirko/src/firefox/gecko2/obj-x86_64-pc-linux-gnu-debug/dist/bin/libxul.so

and Mirko said there is a libxul.so.sym here: ./obj-x86_64-pc-linux-gnu-debug/dist/crashreporter-symbols/libxul.so/7FBE15CCD52645B07F06541D20FF94EF0/libxul.so.sym.

fix-stacks used to be more lenient about accepting breakpad symbol directories, prior to your change in #33. Could this outcome happen (i.e. mismatched UUIDs) if somebody generated symbols and then made some more code changes and recompiled without regenerating symbols?

(In reply to Nicholas Nethercote [:njn] from comment #4)

Mirko: I'm surprised that breakpad symbols are present if you didn't run mach buildsymbols.

I did. Just not when I filed this bug. When writing c3, I ran ./mach buildsymbols.

I am experiencing similar things with fix_stack.py.

207  fix-stacks: error: failed to read symbols file `/home/sefeng/.local/workspace/mozilla/.build/gamma-debug/dist/crashreporter-symbols/libxul.so/7ECF3E933F800043307750BF78C98F630/libxul.so.sym` for `/home/sefeng/.local/workspace/mozilla/.build/gamma-debug/dist/bin/libxul.so`
   1 fix-stacks: note: this is expected and harmless for system libraries on debug automation runs

and I have never ran ./mach builsymbols manually before.

Sean, do you have a libxul.so.sym file somewhere within your objdir?

Flags: needinfo?(sefeng)

Yeah I do have it. I have one as dist/crashreporter-symbols/libxul.so/7ECF3E933F800043307750BF78C98F630/libxul.so.sym.

Note that I did a ./mach buildsymbols command after I left my previous comment, so I am not sure if this file was created by the command if the buildsymbols command can possibly create a file like this.

Flags: needinfo?(sefeng)

The crashreporter-symbols dir seems to get created every time I do a build (no buildsymbols) and I have to remove it otherwise I get an error every time a stack is output during a mochitest run.

Even though I've manually removed the crashreporter-symbols directory, I still encounter the same issue when using fix-stacks.

fix-stacks: error: failed to read symbols file `/home/sefeng/.local/workspace/mozilla/.build/alpha-debug/dist/crashreporter-symbols/libxul.so/42006BF0C0AD9F23238DAC0A32273AB80/libxul.so.sym` for `/home/sefeng/.local/workspace/mozilla/.build/alpha-debug/dist/bin/libxul.so`
fix-stacks: note: this is expected and harmless for system libraries on debug automation runs
fix-stacks: No such file or directory (os error 2)

I have the problem mentioned in comment 10 as well. What is additionally annoying is that on a crash, a huge report is output that overflows my scrollback buffer, so without additional precautions (tee'ing, less or cancelling early on), I have no idea what actually failed.

For some scenarios, attaching gdb with --disable-e10s and manually generating the stacktrace with bt is a temporary workaround.

Is it possible to fix this? While the workaroudn mentioned by Mirko is sometimes possible, in case of intermittent issues this is not an option, and generally it has significant overhead.

Flags: needinfo?(gsvelto)

I'll look at this on Monday.

Assignee: nobody → gsvelto
Severity: -- → S3
Status: NEW → ASSIGNED
Flags: needinfo?(gsvelto)
Priority: -- → P2

Quick update: working on this right now

I think there's two issues here: the first one has to do with the .sym files. The fix-stacks script will normally use the native debug information in a build, but if you have .sym files around it seems that its behavior might be different so I'm checking that out. As for the large report that Simon mentions in comment 11 that's the output of the mindump stackwalker analyzing the crash and it is its default behavior.

Unfortunately I really couldn't reproduce the issue where fix-stacks can't find the symbols. Simon, Sean, do you have a reliable STR for that? As for the exceptional amount of logging after a crash is encountered that's because since bug 1658733 we've been instructing the test harness to pick up the minidump_stackwalk tool automatically. Before most developers simply did not have it on their machines and so they would not set MINIDUMP_STACKWALK when running tests. With that env variable empty we wouldn't run it on crashes and so no output was seen; that was the default behavior for years until bug 1658733 changed it by setting MINIDUMP_STACKWALK by default. One way to avoid the tool's output is to simply unset that env var when running tests.

Flags: needinfo?(sgiesecke)
Flags: needinfo?(sefeng)

I don't have an STR. It used to start to happen very frequently for me (or always)? However, it's been getting better, maybe due to I changed to a new machine so some stuff changed. I still encountered it once a few days ago though.

I'll keep an eye on this and see if I can find anything next time when I see it.

Flags: needinfo?(sefeng)

Thanks. In the meantime I'll upgrade fix-stacks to use a more recent version of symbolic so that we keep it in line with dump_syms. There have been some fixes in how it reads debuginfo so it's worth a try.

Re STR: It doesn't work for me in all my workspaces right now. I don't know if it would work on a clean checkout, I could try that. I vaguely remember that at some point in the last 5 months it was working, but I may be mistaken about that.

Can I run fix-stacks manually somehow, maybe with some debug parameters, to understand why it's failing?

Flags: needinfo?(sgiesecke) → needinfo?(gsvelto)

We don't have much in the way of debugging but I can write a patch to do that, then we apply it locally to your build so that you can gather diagnostic output. BTW I tried updating fix-stacks to pick up a more recent version of symbolic but it messes up how it finds files for macOS so there might be problems lurking into the file-finding logic.

Simon can you rebuild fix-stacks from this branch, replace the executable under $HOME/.mozbuild/fix-stacks/ with the patched one and reproduce? It will spew all the files it's trying to read so we can figure out what's going wrong.

Flags: needinfo?(gsvelto) → needinfo?(sgiesecke)

Sure :) I did, and I got this output:

pid:17825 Assertion failure: false, at /home/simon/work/mozilla-unified/dom/quota/ActorsParent.cpp:2730
Initializing stack-fixing for the first stack frame, this may take a while...
Looking for symbols in folder = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols
Looking for breakpad symbols in bin_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
Looking for breakpad symbols in path = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
bin_base = libxul.so
db_seg = libxul.so
db_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libxul.so
uuid_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libxul.so/7B4B6186D6B94A25CAE006838DE592990
sym_seg = libxul.so.sym
sym_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libxul.so/7B4B6186D6B94A25CAE006838DE592990/libxul.so.sym
fix-stacks: error: failed to read symbols file `/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libxul.so/7B4B6186D6B94A25CAE006838DE592990/libxul.so.sym` for `/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so`
fix-stacks: note: this is expected and harmless for system libraries on debug automation runs
fix-stacks: No such file or directory (os error 2)
 0:03.79 pid:17825 #01: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0x9f801ae]
 0:03.79 pid:17825 #02: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0xaedf73a]
 0:03.79 pid:17825 #03: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0xaedf482]
 0:03.79 pid:17825 #04: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0x698d263]
 0:03.79 pid:17825 #05: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0x69fc17d]
 0:03.80 pid:17825 #06: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0x77cfdaf]
 0:03.80 pid:17825 #07: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so + 0xbe8fc44]
Looking for symbols in folder = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols
Looking for breakpad symbols in bin_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/xpcshell
Looking for breakpad symbols in path = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/xpcshell
bin_base = xpcshell
db_seg = xpcshell
db_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/xpcshell
uuid_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/xpcshell/31337B9C535A3BBC3E47608A11B774CA0
sym_seg = xpcshell.sym
sym_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/xpcshell/31337B9C535A3BBC3E47608A11B774CA0/xpcshell.sym
fix-stacks: error: failed to read symbols file `/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/xpcshell/31337B9C535A3BBC3E47608A11B774CA0/xpcshell.sym` for `/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/xpcshell`
fix-stacks: note: this is expected and harmless for system libraries on debug automation runs
fix-stacks: No such file or directory (os error 2)
 0:03.80 pid:17825 #08: ??? [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/xpcshell + 0x36e48]
Looking for symbols in folder = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols
Looking for breakpad symbols in bin_file = /lib64/libc.so.6
Looking for breakpad symbols in path = /lib64/libc.so.6
bin_base = libc.so.6
db_seg = libc.so.6
db_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libc.so.6
uuid_dir = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libc.so.6/3672375101AD8E8026404C98FAA41D720
sym_seg = libc.so.6.sym
sym_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libc.so.6/3672375101AD8E8026404C98FAA41D720/libc.so.6.sym
fix-stacks: error: failed to read symbols file `/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols/libc.so.6/3672375101AD8E8026404C98FAA41D720/libc.so.6.sym` for `/lib64/libc.so.6`
fix-stacks: note: this is expected and harmless for system libraries on debug automation runs
fix-stacks: No such file or directory (os error 2)
 0:03.81 pid:17825 #09: __libc_start_main [/lib64/libc.so.6 + 0x23f43]
 0:03.81 pid:17825 #10: _start [/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/xpcshell + 0x36d1e]
 0:03.81 pid:17825 #11: ??? (???:???)
 0:03.81 pid:17825 ExceptionHandler::GenerateDump cloned child 17833
 0:03.81 pid:17825 ExceptionHandler::SendContinueSignalToChild sent continue signal to child
 0:03.81 pid:17825 ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Flags: needinfo?(sgiesecke)

Alright, I know what's going on and it's super-silly. By default automation tells fix-stacks to use breakpad symbols because those are always available there while the native ones might have been stripped. However the way we decide to use them depends on checking if the corresponding directory exists. In a local build you might have that folder sitting around from a previous build, holding stale symbols since we don't rebuild them automatically.

Note, this is exactly what Nick had already mentioned in comment 2 but I had interpreted his "failing that" line as fix-stacks falling back to native symbols in case breakpad ones were missing. What he actually meant - and I should have figured it out already then - is that the fallback path only happens if the breakpad symbols directory is completely absent.

The fix here is to modify fix-stacks to do the breakpad-to-native fallback automatically because that's the only way to prevent stale breakpad symbols from breaking its functionality (and IMHO is a good match for the principle of least surprise).

Hm, Sean had mentioned in comment 10 that removing the crashreporter-symbols directory didn't help and I had stated in comment 11 that it didn't help for me either at that time. I can't tell of course if that was accurate.

I now checked and indeed the directory was there. When I remove it, I get:

pid:445 Assertion failure: false, at /home/simon/work/mozilla-unified/dom/quota/ActorsParent.cpp:2649
Initializing stack-fixing for the first stack frame, this may take a while...
Looking for native debug info in bin_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
thread 'main' panicked at 'attempted to leave type `base::Symbol` uninitialized, which is invalid', /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/mem/mod.rs:665:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and when I set RUST_BACKTRACE=1:

pid:3892 Assertion failure: false, at /home/simon/work/mozilla-unified/dom/quota/ActorsParent.cpp:2649
Initializing stack-fixing for the first stack frame, this may take a while...
Looking for native debug info in bin_file = /home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
thread 'main' panicked at 'attempted to leave type `base::Symbol` uninitialized, which is invalid', /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/mem/mod.rs:665:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/panicking.rs:50:5
   3: core::mem::uninitialized
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/mem/mod.rs:665:9
   4: dmsort::dmsort::unsafe_push
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/dmsort-1.0.0/src/dmsort.rs:219:11
   5: dmsort::dmsort::sort_move_by
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/dmsort-1.0.0/src/dmsort.rs:272:5
   6: dmsort::dmsort::sort_by
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/dmsort-1.0.0/src/dmsort.rs:355:2
   7: dmsort::dmsort::sort_by_key
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/dmsort-1.0.0/src/dmsort.rs:369:2
   8: <symbolic_debuginfo::base::SymbolMap as core::convert::From<alloc::vec::Vec<symbolic_debuginfo::base::Symbol>>>::from
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-debuginfo-7.5.0/src/base.rs:376:13
   9: <T as core::convert::Into<U>>::into
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/convert/mod.rs:537:9
  10: <symbolic_debuginfo::base::SymbolMap as core::iter::traits::collect::FromIterator<symbolic_debuginfo::base::Symbol>>::from_iter
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-debuginfo-7.5.0/src/base.rs:399:9
  11: core::iter::traits::iterator::Iterator::collect
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/iter/traits/iterator.rs:1690:9
  12: symbolic_debuginfo::elf::ElfObject::symbol_map
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-debuginfo-7.5.0/src/elf.rs:221:9
  13: symbolic_debuginfo::elf::ElfObject::debug_session
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-debuginfo-7.5.0/src/elf.rs:242:23
  14: symbolic_debuginfo::object::Object::debug_session
             at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-debuginfo-7.5.0/src/object.rs:265:35
  15: fix_stacks::Fixer::build_file_info_direct
             at /home/simon/src/fix-stacks/src/main.rs:426:29
  16: fix_stacks::Fixer::build_file_info
             at /home/simon/src/fix-stacks/src/main.rs:331:32
  17: fix_stacks::Fixer::fix
             at /home/simon/src/fix-stacks/src/main.rs:747:23
  18: fix_stacks::main_inner
             at /home/simon/src/fix-stacks/src/main.rs:879:38
  19: fix_stacks::main
             at /home/simon/src/fix-stacks/src/main.rs:887:23
  20: core::ops::function::FnOnce::call_once
             at /rustc/80184183ba0a53aa4f491753de9502acd3d6920c/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
 0:05.70 pid:3892 
 0:05.70 ERROR dom/quota/test/xpcshell/test_getUsage.js | Process still running after test!
 0:05.71 INFO Following exceptions were raised:
 0:05.71 ERROR Traceback (most recent call last):
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 228, in run
    self.run_test()
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 835, in run_test
    process_output, _ = self.communicate(proc)
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 293, in communicate
    self.process_line(line)
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 691, in process_line
    self.report_message(line_string)
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 674, in report_message
    self.log_line(message)
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 648, in log_line
    line = self.fix_text_output(line).rstrip("\r\n")
  File "/home/simon/work/mozilla-unified/testing/xpcshell/runxpcshelltests.py", line 641, in fix_text_output
    return self.stack_fixer_function(line)
  File "/home/simon/work/mozilla-unified/testing/mozbase/mozrunner/mozrunner/utils.py", line 290, in stack_fixer_function
    line, slowWarning=True, hide_errors=hideErrors
  File "/home/simon/work/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/fix_stacks.py", line 91, in fixSymbols
    fix_stacks.stdin.write(line)
IOError: [Errno 32] Broken pipe

That seems like an unrelated issue, though?

Yes, that is odd. I'm now attempting to reproduce locally, maybe there's more than one problem lurking in this code (and I'm not sure how it interacts with the rest of the automation stuff, if for example the breakpad symbols directory gets re-created even when we don't run ./mach buildsymbols).

Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1bf8061fa589
Import a new version of fix-stacks with proper fallback to native debuginfo support when breakpad symbols are missing r=KrisWright

https://hg.mozilla.org/mozilla-central/rev/1bf8061fa589

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox87: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: