Closed Bug 1142944 Opened 5 years ago Closed 4 years ago
crash in EMPTY: no crashing thread identified; ERROR
_NO _THREAD _LIST
40.19 KB, text/plain
84.41 KB, text/plain
1.21 KB, patch
|Details | Diff | Splinter Review|
This bug was filed from the Socorro interface and is report bp-d890afcb-97d9-4548-b6f0-812d72150313. ============================================================ Sony Xperia Z2 (4.4.4) Galaxy Note (4.4.2) STR's: 1. Open Firefox with a clean profile 2. Go to youtube.com and 'Request for the desktop' site 3. Play a flash video and tap on the fullscreen button Result: FF crashes Note: This only happens when entering in fullscreen for the first time on a profile. In order to reproduce the crash a second time, you'll have to clear your profile and run this steps again. Sometimes you'll have to leave the video playing in full screen for a few seconds but eventually Firefox will crash Reproducible on Firefox 37 and Firefox 36 including 36.0.2
This is not a recent regression. We were able to reproduce it on 34.0.1
I am able to reproduce this on every page that has flash content when activating plugin. Device: Nexus 9 (Android 5.1.1) I think this is a P1 bug; ranked #4 in Firefox 40.0.3
4 years ago
Assignee: nobody → snorp
tracking-fennec: ? → +
[Tracking Requested - why for this release]: This was a topcrash on 41. Not sure how it will look yet in 42 release. Sylvestre you may want to take a look after we have more data for 42.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #3) > This was a topcrash on 41. Not sure how it will look yet in 42 release. > Sylvestre you may want to take a look after we have more data for 42. This is a pretty generic signature that is not really actionable because the crash data doesn't really give us any information as to what crashed.
Too late for 42, not tracking.
I can reproduce by going to about:profiles and clicking on Create New Profile and tapping in the resulting white screen. https://crash-stats.mozilla.com/report/index/bp-c191ab63-37a7-451a-b190-9da8f2151219 https://crash-stats.mozilla.com/report/index/bp-b6d8ddb1-634f-4b53-b4aa-49d052151219
Margaret, here is another top crasher on 44.0b2. Copying below product level breakdown for 7 days of data: Product Version Count Percentage Installations FennecAndroid 43.0 20303 70.2% 15217 FennecAndroid 42.0.2 1324 4.6% 1145 FennecAndroid 41.0.2 982 3.4% 650 FennecAndroid 44.0b2 622 2.2% 469 Given that Ehsan has a repro, could you please help investigate/assign an owner? I would love to take a fix for this in Beta44. Thanks for your help!
snorp is currently assigned, but maybe this needs higher priority.
tracking-fennec: + → ?
Hi, A crash with the same signature could be reproduced on a Xiami Mi i4 phone with 5.0.2 Android version when "Full-screen browsing" option is tapped in order to activate or deactivate. This issue was reproduced on the Nightly build 46.0a1 2016-01-03 https://crash-stats.mozilla.com/report/index/b3d6a64b-9fdd-47b3-94d2-52e222160104 Please note that this issue could be reproduced with a 100% rate
I saw this on my Nexus 5X this morning. Happened when I switched back to the app after I had tabs queued in the background (and it lost my tab queue, which isn't good, but likely another problem).
This is happening every now and then on my N6P. Always when resuming the app so far, I think. Some of my crash reports: * https://crash-stats.mozilla.com/report/index/9bba334c-4f91-48f2-9f2b-82e8a2160104 * https://crash-stats.mozilla.com/report/index/55729c56-a08c-4baa-bd64-f77d62151230 * https://crash-stats.mozilla.com/report/index/86f0aff6-e1bb-41c1-829a-b3bc12160105
(In reply to mihai.ninu from comment #9) > Hi, > A crash with the same signature could be reproduced on a Xiami Mi i4 phone > with 5.0.2 Android version when "Full-screen browsing" option is tapped in > order to activate or deactivate. This issue was reproduced on the Nightly > build 46.0a1 2016-01-03 > > https://crash-stats.mozilla.com/report/index/b3d6a64b-9fdd-47b3-94d2- > 52e222160104 > > Please note that this issue could be reproduced with a 100% rate Can you file a separate bug about this that blocks this bug? We should also make sure there's a bug filed on getting useful stacks for these crashes, since they're not actionable. Sebastian, if you or I notice reliable STR, we should file a separate bug about that.
tracking-fennec: ? → +
Flags: needinfo?(snorp) → needinfo?(mihai.ninu)
Catalin - Can you get a logcat of the crash on Fx44? We don't get any logcats in crash-stats for this bug since nothing is uploaded in that part of the crash report.
or Mihai, if Catalin is working on iOS stuff
I'm able to reproduce this crash on different pages (e.g imdb.com) when activating the plugin content
(In reply to Catalin Suciu [:csuciu] from comment #15) > Created attachment 8707790 [details] > log.txt > > I'm able to reproduce this crash on different pages (e.g imdb.com) when > activating the plugin content Thanks. I see a few lines near the top like this: GeckoPlugins: get xxx Then we seem to crash, but I don't see any useful information about the crash at all. Just a log line about the windowin dying. Then I see some exceptions due to Fennec being dead, but those are'nt the reason we crashed. I wonder if it's possible to install a debug version of Fx44 and get a big log from that? http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-beta-android-api-11-debug/1452766055/
libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc6f9d0f0 in tid 18463 (FP_DoPlay) Could this be a hint?
I can reproduce this signature simply by using the Crash Me (Simple) add-on on the 6P https://addons.mozilla.org/en-US/android/addon/crash-me-now-simple/?src=search
Jim, can you look at this? I build on Mac so I can't build breakpad and it's looking more difficult to build there than expected. I'm also setting up to build on my linux VM. This seems to be a relatively easy thing to repro on the 6P (and maybe any Marshmallow device?)
Assignee: snorp → nchen
I was able to reproduce this signature using the Crashme add-on on HTC Nexus 9 (Android 6.0)
PTRACE_GETFPREGS fails on this device. The latest breakpad code does not try to call this on Android, because it fails on 64bit devices. Ugh. We can just remove or comment that out for 44 an 45, but bug 1069556 will fix it otherwise.  https://chromium.googlesource.com/breakpad/breakpad/+/master/src/client/linux/minidump_writer/linux_ptrace_dumper.cc
Assignee: nchen → snorp
Comment on attachment 8712218 [details] [diff] [review] Don't use PTRACE_GETFPREGS when getting crash trace on Android/ARM Review of attachment 8712218 [details] [diff] [review]: ----------------------------------------------------------------- I tried to land the Breakpad update today but it broke some random thing. Hopefully will get that fixed and re-landed today or tomorrow. This should be safer for branch-landing anyway, if that's something you want.
Attachment #8712218 - Flags: review?(ted) → review+
Comment on attachment 8712218 [details] [diff] [review] Don't use PTRACE_GETFPREGS when getting crash trace on Android/ARM Approval Request Comment [Feature/regressing bug #]: Android changes [User impact if declined]: Unable to report crashes on 64-bit device [Describe test coverage new/current, TreeHerder]: local only [Risks and why]: very low, only ifdefs out a small block of code [String/UUID change made/needed]: none
I've tested on Nexus 9(Android 6.0) with the build from http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1453830688/ STR: Go to flashadds.com, activate plugin: https://crash-stats.mozilla.com/report/index/09d7d30b-7240-42a3-8311-f7e262160127 Install crash-me addon: https://crash-stats.mozilla.com/report/index/ebf9d2e7-cc0f-4f0b-9b50-096612160127 The crash signatures are now valid, different ones from "EMPTY: no crashing thread identified; ERROR_NO_THREAD_LIST" I will mark this verfied as fixed on tommorow's Nightly
Comment on attachment 8712218 [details] [diff] [review] Don't use PTRACE_GETFPREGS when getting crash trace on Android/ARM Improve the crash reporting, taking it. Should be in 45 beta 2
Hi Snorp, I am starting to plan a Fennec 44.0.1 which will gtb today most likely. Do you still want me to take this as ride-along? If so, please nominate for uplift to m-r. Also, do we have verified data that this fix has improved diagnosing some of the crashes and therefore worthwhile uplifting to 44.0.1. Thanks!
We actually still see this signature on Beta. The patch does help, but apparently we still have something else going on. I don't have strong feelings about uplifting this to release at this point.
¡Hola James! Just crashed like https://crash-stats.mozilla.com/report/index/1381b586-4f44-4a99-873d-e70672160929 Also there are other 6678 crashes in the past week at https://crash-stats.mozilla.com/signature/?product=FennecAndroid&signature=EMPTY%3A%20no%20crashing%20thread%20identified%3B%20ERROR_NO_THREAD_LIST Shall this be reopened or a new bug filed? ¡Gracias! Alex
(In reply to alex_mayorga from comment #35) > ¡Hola James! > > Just crashed like > https://crash-stats.mozilla.com/report/index/1381b586-4f44-4a99-873d- > e70672160929 > > Also there are other 6678 crashes in the past week at > https://crash-stats.mozilla.com/signature/ > ?product=FennecAndroid&signature=EMPTY%3A%20no%20crashing%20thread%20identifi > ed%3B%20ERROR_NO_THREAD_LIST > > Shall this be reopened or a new bug filed? > > ¡Gracias! > Alex A new bug, I think. There are many different reasons we could end up with an empty crash and this bug only solved one such case.
You need to log in before you can comment on or make changes to this bug.