1960108 - A Firefox 137 tab crashed on YouTube [@ EMPTY: no frame data available; EmptyMinidump ]

Status: ASSIGNED

(Toolkit :: Crash Reporting, defect)

Description

[Vincent Lefevre]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

I was playing a video on YouTube.

Note: it was a live video, but the live had ended, and I went back to the beginning. There were no issues for several minutes, though.

Actual results:

The tab crashed:

https://crash-stats.mozilla.org/report/index/dd38b4fd-34ac-43fa-b073-66f810250411

Expected results:

The tab should not have crashed. In case of unexpected event with YouTube, it should have been handled gracefully.

Comment 1

[Vincent Lefevre]

Note: a few month ago, I got a similar crash on YouTube with Firefox 134: bug 1941903.

Comment 2

[Vincent Lefevre]

In the journalctl output, at the time of the crash, I can see:

Apr 12 00:53:13 qaa kernel: Isolated Web Co[501773]: segfault at 0 ip 00007fe3c75ec512 sp 00007ffd83150cc0 error 6 in libxul.so[7fe3c7233000+6545000] likely on CPU 6 (core 12, socket 0)
Apr 12 00:53:13 qaa kernel: Code: cc cc cc cc cc cc cc cc f3 0f 1e fa 50 e8 f6 a7 ce 03 48 8d 05 e3 d3 11 fd 48 8b 0d d8 a6 66 06 48 89 01 31 c0 b9 b1 02 00 00 <48> 89 08 e8 96 0c 18 06 cc cc cc cc cc cc f3 0f 1e fa 50 48 89 f7

Comment 3

[Karl Tomlinson (:karlt)]

If we can work out why the crashreporter is not collecting a stack, we might be able to get some more helpful info next time.

CPU Info unknown
5.87 GB Available Physical Memory

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gsvelto, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Vincent Lefevre]

I've just got another crash with FF 138 on a live video.

Comment 6

[Gabriele Svelto [:gsvelto]]

We only have failed to write dump file as the reason why this failed, but we should have a more detailed reason. Chris, are we accidentally overwriting the underlying reason for not having a minidump here? In this case the file appears to be completely empty, but I can't really tell why.

Comment 7

[Chris Martin [:cmartin]]

I will have to investigate this when I'm done with the debugger rendezvous change :)

Comment 8

[Vincent Lefevre]

I've just got a crash on YouTube with FF 140.0.1 while the video wasn't even playing!

Comment 9

[Alex Franchuk [:afranchuk]]

(In reply to Gabriele Svelto [:gsvelto] from comment #6)

We only have failed to write dump file as the reason why this failed, but we should have a more detailed reason. Chris, are we accidentally overwriting the underlying reason for not having a minidump here? In this case the file appears to be completely empty, but I can't really tell why.

Yeah, I think that is hiding it. We should change err_to_error_msg to create a string with the full error context (.to_string() will only show the last context). E.g., we could do format!("{e:#}") instead.