This bug was filed from the Socorro interface and is report bp-ef7fe786-b07c-4b8d-9d3f-0d2d42150310. ============================================================= We have many crashes with this signature, but at least some of them are a crash in cubeb_opensl.c, opensl_init(). I think most of them are a segfault at 0xdeadbaad, which is what happens when the JVM aborts. Usually this is because you are trying to invoke a method via JNI and there is a pending exception. I believe some devices have OpenSL drivers that wrap AudioTrack via JNI, so that's probably going bad. Not sure if we can find a way to work around that or not.
Tracking 37+ as this is an offshoot of top crash bug 1126561. Given where we are in 37, we may need to ship 37 with this crash. Anthony - Do you have anyone available to investigate?
Paul - any thoughts?
Short of having the right libc.so to dig out symbols, or a device that can repro, it's not clear to me what happens here.
From searching around, 0xdeadbaad also shows up with heap corruption. I haven't seen anything like this before and there's not much to go on from the stacks as they all point to line 307 in cubeb_opensl.c, which is the closing brace of opensl_init. There haven't been many changes to this code for a fair while, either. I think the last think was the shared OpenSL engine stuff from GCP. Gian-Carlo: any ideas? Have you seen anything like this before with OpenSL?
We need more clues in order to progress this.
I think it's likely this is only happening on some hardware/OS combination. Once bug 1142767 lands, we may be able to figure that out.
I don't see a lot of crashes for 37b4 and we're not going to have a fix ready by b8 gtb on Monday. I'm marking this as wontfix for 36 and 37.
The crashes are being reprocessed, so we might find more details.
The original "pending JNI exception on opensl call" sounds possible but there's nothing actionable here for me.
I don't see any specific device or hardware that seems common. Most common device is at around 3% of all crashes and there is a very long tail of devices. See https://crash-stats.mozilla.com/report/list?product=FennecAndroid&range_unit=days&range_value=28&signature=opensl_init#tab-sigsummary Emailing snorp a list of URLs.
Check to see if SV can repro with URLs
Given that the request is for SoftVision, let's go direct to Ioana.
Florin, can you help on this? Thanks
I think this is in Ioana's yard since she handles the Mobile side... unless there's something to do on the Desktop side as well... is there anything?
Sorry for late reply - we did test it that Friday, April 10th on several devices we have in house but we were not able to reproduce nor see it at all. For the list in Kevin's comment we might contact the contributors to see who has those from the peak but super low chances.
Don't see this after Firefox 37 beta 6. People hitting this should upgrade to a current Firefox for Android.
OK, marking 38 as fixed then
Marking 39 as fixed based on comment 16.
If this has disappeared in 38 and 39, we might as well mark it fixed? Please reopen if I'm wrong!