Closed Bug 1150510 Opened 9 years ago Closed 9 years ago

Crash [@ nsStringBundle::GetStringFromName(char16_t const*, char16_t**) ]

Categories

(Core :: Disability Access APIs, defect)

40 Branch
x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla41
Tracking Status
firefox39 --- verified
firefox40 --- verified
firefox41 --- verified

People

(Reporter: robin, Assigned: surkov)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150401180920

Steps to reproduce:

Turned on Voiceover and focused Nightly.


Actual results:

Crash, after about a second of Voiceover speaking.


Expected results:

No crash. Originally I hit this on the popup window that lets you know that e10s isn’t compatible with Voiceover, but I’ve hit it twice more since then with e10s disabled (automatically, via bug 1047076). Sample crash log: https://crash-stats.mozilla.com/report/index/2f282688-9e89-4ff9-b175-cc8212150402
This is with OS X 10.10.2
Severity: normal → critical
Crash Signature: @ nsStringBundle::GetStringFromName(char16_t const*, char16_t**)
Component: Untriaged → Disability Access APIs
Product: Firefox → Core
Alex, any idea why this might be crashing? I looked, and there are definitely no mismatches between the localization tokens and the tokens in the RoleDescrMap.
Flags: needinfo?(surkov.alexander)
OK, I can reproduce this, too, just by starting current Nightly with VoiceOver running. It's an immediate startup crash for me.
https://crash-stats.mozilla.com/report/index/cbd94384-c2bf-423b-aee3-3cf292150402
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(surkov.alexander)
Keywords: crash
Summary: Crash when interacting with Voiceover → Crash [@ nsStringBundle::GetStringFromName(char16_t const*, char16_t**) ]
Whoops, didn't mean to clear the needinfo.
Flags: needinfo?(surkov.alexander)
I think the earliest build date crash report is: 20150307030233
I cannot reproduce it (fresh debug nightly) and nothing evident from the stack I see. Marco, any chance you can debug it?
Flags: needinfo?(surkov.alexander)
Not looking good ATM. Besides, VoiceOver interaction makes the browser and subsequently VoiceOver freeze as soon as it halts. Same problem as on Windows. Can you try with a release build and see if that reproduces for you? May be something that doesn't affect debug builds.
I can confirm this crashes on multiple computers in English and non-English release builds, including the latest build from 2015-04-13. Alex, any more luck reproducing it on your end? David, can you perhaps help?
Flags: needinfo?(surkov.alexander)
Flags: needinfo?(dbolter)
Doesn't reproduce for me. I tried my regular profile as well as a blank one I keep around.
OSX 10.10.3
Flags: needinfo?(dbolter)
Hhmmm that is very strange! I use 10.10.3, too, and I get this crash virtually right after launch. I, of course, have VoiceOver already running when I launch Firefox. Wonder if that makes a difference. Reproduces on two Macs for me.
Flags: needinfo?(dbolter)
I had VO running before launch (followed comment 3).
Flags: needinfo?(dbolter)
As said on IRC, also try issuing a VoiceOver command like Ctrl+Option+RightArrow or Ctrl+Option+LeftArrow after you launch it and Firefox. It may need that to trigger the crash.
Robin, what locale is your Mac set to? Anything other than English by any chance? (System Preferences/Languages).
Flags: needinfo?(robin)
Reproduced it just now. My STR:
1. start VO
2. start FF, select my regular profile (I start with profile manager)
3. try ctrl option left/right
4. observed no speech
5. switch to another app, heard speech
6. switch back to FF
7. boom!

Similar stack. No adjustment of locale needed.

FWIW: browser.tabs.remote.autostart.disabled-because-using-a11y was already true (from a previous run), so no doorhanger.
Marco, it’s English, but en-GB if that makes any difference.
Flags: needinfo?(robin)
Alex, as per IRC Marco suspects bug 1137714 (your bug).
(In reply to David Bolter [:davidb] from comment #15)
> Reproduced it just now. My STR:
> 1. start VO
> 2. start FF, select my regular profile (I start with profile manager)
> 3. try ctrl option left/right
> 4. observed no speech
> 5. switch to another app, heard speech
> 6. switch back to FF
> 7. boom!
> 
> Similar stack. No adjustment of locale needed.
> 
> FWIW: browser.tabs.remote.autostart.disabled-because-using-a11y was already
> true (from a previous run), so no doorhanger.

no luck. can you debug it?
Flags: needinfo?(surkov.alexander)
(In reply to alexander :surkov from comment #18)
> (In reply to David Bolter [:davidb] from comment #15)

> no luck.

Can you try a release build of nightly?
Flags: needinfo?(surkov.alexander)
I've built a local release build with
ac_add_options --disable-optimize
ac_add_options --enable-accessibility
ac_add_options --enable-debug-symbols

no crash. However I see the crash on downloaded Nightly. Is there any guidance on how to debug it?
Flags: needinfo?(surkov.alexander)
(In reply to alexander :surkov from comment #20)
 
> no crash. However I see the crash on downloaded Nightly. Is there any
> guidance on how to debug it?

You could try something like https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server and if you have trouble I'd ask around on #developers, probably bsmedberg or ted know more.
(In reply to alexander :surkov from comment #20)
> I've built a local release build with
> ac_add_options --disable-optimize
> ac_add_options --enable-accessibility
> ac_add_options --enable-debug-symbols
> 
> no crash. However I see the crash on downloaded Nightly. Is there any
> guidance on how to debug it?

try enabling optimization? and if that crashes then debug that.
Friendly ping. Progress anyone?
(In reply to Trevor Saunders (:tbsaunde) from comment #22)

> try enabling optimization? and if that crashes then debug that.

same, not crash
(In reply to alexander :surkov from comment #24)
> (In reply to Trevor Saunders (:tbsaunde) from comment #22)
> 
> > try enabling optimization? and if that crashes then debug that.
> 
> same, not crash

Might be best to try the downloaded nightly and https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_Mac_OS_X (Or did you try that?)
Flags: needinfo?(surkov.alexander)
Hi Mark, any ideas? (I noticed you touched some code around here, feel like investigating this crash?)
Flags: needinfo?(markcapella)
Attached patch patchSplinter Review
Flags: needinfo?(surkov.alexander)
Attachment #8623723 - Flags: review?(mzehe)
Comment on attachment 8623723 [details] [diff] [review]
patch

r=me, fixes the crash.
Flags: needinfo?(markcapella)
Attachment #8623723 - Flags: review?(mzehe) → review+
Came in late ... glad you caught it :)
https://hg.mozilla.org/mozilla-central/rev/1b5e08c07572
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment on attachment 8623723 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 1137714
[User impact if declined]: Users running with accessibility on OS X will receive a startup crash, particularly with VoiceOver.
[Describe test coverage new/current, TreeHerder]: Treeherder, manual verification of fix.
[Risks and why]: No risk.
[String/UUID change made/needed]: None.
Attachment #8623723 - Flags: approval-mozilla-beta?
Attachment #8623723 - Flags: approval-mozilla-aurora?
Comment on attachment 8623723 [details] [diff] [review]
patch

Fix for startup crash/accessibility. Approved for uplift to beta and aurora
Attachment #8623723 - Flags: approval-mozilla-beta?
Attachment #8623723 - Flags: approval-mozilla-beta+
Attachment #8623723 - Flags: approval-mozilla-aurora?
Attachment #8623723 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
Reproduced with Nightly 2015-04-13: bp-7f37c55c-6abb-43ff-96eb-97e3b2150622
Verified fixed with 39.0b7 (Build ID: 20150618135210), latest 40.0a2 (from 2015-06-19) and 41.0a1 (from 2015-06-21), under Mac OS X 10.10. Also found bug 1176683 while verifying this fix on Developer Edition.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Comment on attachment 8623723 [details] [diff] [review]
patch

> struct RoleDescrMap
> {
>   NSString* role;
>-  const nsString& description;
>+  const nsString description;

So I believe that does fix a bug, but in a very inefficient way.  Now at start up you'll construct a bunch of strings that each own a string buffer holding a copy of the constant strings.  So you'll do a bunch of mallocing and copying for no useful purpose.  Instead I think you could use nsDependantString or just store a char16_t * pointing at the constant and then create a temporary nsString when  and if if you need it to pass to the TranslateString function.
not sure if nsDependantString works, but char* should do a trick. Filed bug 1183303.
You need to log in before you can comment on or make changes to this bug.