986250 - nsLocalFile::Create() crashes B2G content process

Status: RESOLVED DUPLICATE of bug 973090

(Core :: XPCOM, defect)

Description

[Diego Wilson [:diego]]

Attachment: minidump

Comment 1

[Diego Wilson [:diego]]

Attachment: extra

Comment 2

[Diego Wilson [:diego]]

Hi Brendan,

Is this the right component for this bug?

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[Diego Wilson [:diego]]

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.

Comment 5

[Preeti Raghunath(:Preeti)]

moving to 1.4? till we receive the right symbols

Comment 6

[Preeti Raghunath(:Preeti)]

We're awaiting symbols here, please do not change flags in the meantime

Comment 7

[Preeti Raghunath(:Preeti)]

Inder,

Lets minus till symbols are provided

Comment 8

[Inder]

Preeti -- sure, fine by me.

Jason -- not sure i understand the logic to move it to backlog when it's being actively investigated?

Comment 9

[Jason Smith [:jsmith]]

(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.

Comment 10

[Diego Wilson [:diego]]

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.

Comment 11

[Diego Wilson [:diego]]

Guillaume,

Please see comment 10.

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

 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.