Closed Bug 986250 Opened 7 years ago Closed 7 years ago
Local File::Create() crashes B2G content process
No description provided.
blocking-b2g: --- → 1.4?
Crash Signature: nsLocalFile::Create(unsigned int, unsigned int) | nsMemoryInfoDumper::OpenTempFile(nsACString_internal const&, nsIFile**) | nsCycleCollectorLogger::CreateTempFile(char const*)
Hi Brendan, Is this the right component for this bug?
This is a crash in libc.so which doesn't have symbols in your crash. Can you get symbols for it? Also what tree/revision does this report come from? nsLocalFileUnix.cpp : 472 + 0x7 is nsLocalFile::Create calling CreateAndKeepOpen and I think we're skipping that frame because of the busted libc symbols, so we really need to know the line number for CreateAndKeepOpen and probably what it is calling.
Flags: needinfo?(brendan) → needinfo?(dwilson)
Sorry for the lack of updates. This issue is difficult to reproduce consistently. It only happens during automated testing but it's not clear exactly where in our tests. I'll update again once I can get more details.
moving to 1.4? till we receive the right symbols
blocking-b2g: 1.4+ → 1.4?
We're awaiting symbols here, please do not change flags in the meantime
Inder, Lets minus till symbols are provided
Preeti -- sure, fine by me. Jason -- not sure i understand the logic to move it to backlog when it's being actively investigated?
(In reply to Inder from comment #8) > Preeti -- sure, fine by me. > > Jason -- not sure i understand the logic to move it to backlog when it's > being actively investigated? There was a decision made in drivers that we need to make more swift blocking decisions, which means that we need to get bugs out of the nomination queue quickly after being nominated. In cases where we are blocked on information, the decision was made that we need make the decision based on what we know right now. In this case, this isn't actionable, so it got moved to backlog. When the bug becomes actionable again, then we can renominate the bug to block.
I double checked that the symbols are present, so not sure why the stack isn't unwinding so nicely. But I think I found the root cause. It's looking like another SECCOMP issue. @Guillaume Is this another syscall that needs to be whitelisted? 01-01 00:02:33.949 1182 1182 E Sandbox : seccomp sandbox violation: pid 1182, syscall 39, args 2931552424 511 511 3204401020 511 3204401020. Killing process.
Guillaume, Please see comment 10.
3 libxul.so!nsCycleCollectorLogger::CreateTempFile(char const*) [nsCycleCollector.cpp : 1730 + 0x7] Assuming the stack isn't misunwound here, this is bug 973090 — GC/CC logging isn't e10s-enabled yet. (In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > This is a crash in libc.so which doesn't have symbols in your crash. Can you > get symbols for it? Also what tree/revision does this report come from? It does have symbols, but they're only for functions with DWARF unwind info — i.e., only functions written in C/C++, not in assembly with ARM EH directives like the syscall wrappers. There's a patch for this in bug 942290. Even with that patch we still don't have names, because breakpad gets those from the DWARF "subprogram" object and ignores the ELF symbol table; I looked into fixing that but it seems to be nontrivial because of how breakpad is structured.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 973090
You need to log in before you can comment on or make changes to this bug.