Closed
Bug 988311
Opened 10 years ago
Closed 10 years ago
Roboform-cased crashes in nsACString_internal::SetCapacity(unsigned int, mozilla::fallible_t const&)
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
VERIFIED
FIXED
Firefox 32
People
(Reporter: tracy, Assigned: away)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 1 obsolete file)
960 bytes,
patch
|
away
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-c4e4f709-0c9b-4e25-839a-5b2522140325. ============================================================= This is a startup crasher on Aurora (fx30) that has been around in light volume for a long time. Something has caused it to rise in volume since builds of 20140321. However, it was creeping up a bit with builds of 20140319 and 20140320. So it's not clear when it regressed exactly.
Updated•10 years ago
|
Component: JavaScript Engine → XPCOM
Comment 1•10 years ago
|
||
This particular example has roboform.dll/rf-firefox-22. Is that common across them all? I wouldn't expect roboform-22 to be loaded into FF30, and I thought roboform stopped using XPCOM binaries altogether...
Flags: needinfo?(twalker)
QA Contact: twalker
Reporter | ||
Comment 2•10 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > This particular example has roboform.dll/rf-firefox-22. Is that common > across them all? I wouldn't expect roboform-22 to be loaded into FF30, and I > thought roboform stopped using XPCOM binaries altogether... Yes, roboform.dll/rf-firefox-22 is common to all the reports.
Updated•10 years ago
|
Blocks: fxdesktoptriage
Component: XPCOM → Extension Compatibility
Product: Core → Firefox
Summary: crash in nsACString_internal::SetCapacity(unsigned int, mozilla::fallible_t const&) → Roboform-cased crashes in nsACString_internal::SetCapacity(unsigned int, mozilla::fallible_t const&)
Comment 3•10 years ago
|
||
bp-af0844d3-25a5-4a5a-9822-5abe32140324 is same issue
Crash Signature: [@ nsACString_internal::SetCapacity(unsigned int, mozilla::fallible_t const&)] → [@ nsACString_internal::SetCapacity(unsigned int, mozilla::fallible_t const&)]
[@ nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*)]
Updated•10 years ago
|
Comment 4•10 years ago
|
||
you should upgrade RoboForm to ver 7.9.5. you use really old version
Updated•10 years ago
|
No longer blocks: fxdesktoptriage
Updated•10 years ago
|
Blocks: fxdesktopbacklog
Whiteboard: p=0
Updated•10 years ago
|
Flags: firefox-backlog?
Comment 5•10 years ago
|
||
dmajor can you just DLL-block this? It's not an updated roboform so it's not actually *working* for these people anyway.
Assignee: nobody → dmajor
Flags: firefox-backlog?
I don't think this is a matter of old versions. The report in comment 0 is up to date: Image name: rf-firefox-22.dll Timestamp: Sat Mar 01 07:04:26 2014 (5310CFAA) File version: 7.9.5.5 Given the compile date, maybe the number means "for 22 and higher"? I think we need to do some more digging on this.
Each of the signatures has only a few dozen reports. Is this really a topcrash?
I saw a crash report on 7.9.6.6 as well. I'm not convinced there's a good enough case to take action here.
Assignee: dmajor → nobody
To be clear, any of these would be good enough in my book: * High volumes * Old roboform only * Clear FF regression * Reproducible ...but I don't see any of these factors here. Let me know if I've overlooked something.
Reporter | ||
Comment 10•10 years ago
|
||
This is no longer a topcrash on Fx30. And the table for this signature is no longer showing why I marked it as such in the first place. :-/
Keywords: topcrash-win
Updated•10 years ago
|
Comment 11•10 years ago
|
||
ok, here is updated info from RoboForm developers. RoboForm2Go crashes Firefox ver 30 (alpha) seen in our dumps and in Firefox's bugzilla too, see this thread for instance. This is because of change in Firefox ABI which is used for injection. I will add new rf-firefox-30.dll compiled with the latest Firefox SDK. The problem is that they did not release it yet in compiled form for Firefox ver 30, so I have to wait. Compiling it locally from sources is not reliable, I tried it in the past and the resulting dll crashed. Is there any chance to get stable versions of ABI before you release them? Or alternatively declare that all binary APIs are totally unstable and nobody should attach to FF from outside using them.
Comment 12•10 years ago
|
||
Our XPCOM ABI is unstable by design. The only safe way to use it is to compile a separate DLL for each release. I thought roboform stopped using binary XPCOM completely?
Comment 13•10 years ago
|
||
RoboForm has stopped using binary API completely. But this is RoboForm2Go, portable version. It attached to Firefox from outside, without being installed, so it needs binary API to get "initial foothold" in the browser. I will ask developers what exactly do we use and what they propose to make it less binary on FF side.
Updated•10 years ago
|
Flags: firefox-backlog+ → firefox-backlog-
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Updated•10 years ago
|
Whiteboard: p=2
Comment 14•10 years ago
|
||
dmajor please add rf-firefox-22 to the DLL blocklist.
Assignee: nobody → dmajor
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Comment 15•10 years ago
|
||
we will fix it soon and publish it. this is for alpha, as I understand
Comment 16•10 years ago
|
||
actually developers tell me that we cannot do a release, since Mozilla did not release SDK for Firefox 30.
Comment 17•10 years ago
|
||
30 SDK appears to be in its normal spot: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/30.0b1-candidates/build1/sdk/
Comment 18•10 years ago
|
||
My other concern is that this DLL was being loaded into Firefox 30 at all. Why would you choose to load this DLL into any future/unknown version of Firefox at all, knowing that it's unlikely to be compatible and will probably cause problems?
Comment 19•10 years ago
|
||
1) we will change to the new API in the next RF version 2) mid-term we will probably just kill RF2Go on Firefox. with lack of stable APIs attaching to browser from outside become too bothersome.
Assignee | ||
Comment 20•10 years ago
|
||
Not sure whether this one is ready to proceed. Let me know if/when.
Attachment #8418572 -
Flags: feedback?(benjamin)
Comment 21•10 years ago
|
||
We will have a new release in 1-2 days that addresses the issue
Comment 22•10 years ago
|
||
Will the new release still have the DLL name rf-firefox-22.dll or will it be something like rf-firefox-30.dll? If it is still rf-firefox-22.dll, what will the DLL version number be? The version number of the current broken version appears to be 7.9.5.5.
Flags: needinfo?(vm)
Comment 23•10 years ago
|
||
it will have a different name DLL name is based on SDK version
Flags: needinfo?(vm)
Comment 24•10 years ago
|
||
Comment on attachment 8418572 [details] [diff] [review] blocklist Let's get the old one blocked in Firefox 30+ then. Thanks.
Attachment #8418572 -
Flags: feedback?(benjamin) → review+
Comment 25•10 years ago
|
||
seems reasonable. I guess it will not cause blocking of this DLL in existing FF ver 29 and earlier? this would be undesirable
Comment 26•10 years ago
|
||
Correct, this block will only apply to FF30+
Assignee | ||
Comment 27•10 years ago
|
||
Patch as landed, updated to all versions of this filename http://hg.mozilla.org/integration/mozilla-inbound/rev/2175e6154ed7
Attachment #8419034 -
Flags: review+
Attachment #8418572 -
Attachment is obsolete: true
Comment 28•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2175e6154ed7
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Assignee | ||
Comment 29•10 years ago
|
||
Comment on attachment 8419034 [details] [diff] [review] Blocklist rf-firefox-22.dll These crashes aren't super huge volume but I'm flagging per comment 24. [Approval Request Comment] Bug caused by (feature/regressing bug #): RoboForm2Go User impact if declined: Crashes Testing completed (on m-c, etc.): been on m-c a few days Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #8419034 -
Flags: approval-mozilla-beta?
Attachment #8419034 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
status-firefox32:
--- → fixed
Updated•10 years ago
|
Attachment #8419034 -
Flags: approval-mozilla-beta?
Attachment #8419034 -
Flags: approval-mozilla-beta+
Attachment #8419034 -
Flags: approval-mozilla-aurora?
Attachment #8419034 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 30•10 years ago
|
||
Sheriffs: the patch will apply more easily if you uplift bug 1002748 before this one.
Comment 31•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/69aff1330269 https://hg.mozilla.org/releases/mozilla-beta/rev/79e75d908e1d
Updated•10 years ago
|
status-b2g-v1.4:
--- → fixed
Reporter | ||
Comment 33•10 years ago
|
||
There is but a single report of this crash (on 30.0Beta5) since this landed everywhere. It is one of type [@ nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*)]. https://crash-stats.mozilla.com/report/index/665c24a0-2612-4ae1-8517-61f5c2140518 If this particular signature happens to rise significantly volume, I'll file a new bug for it only.
Status: RESOLVED → VERIFIED
Comment 34•10 years ago
|
||
RoboForm2Go ver 7-9-7 has been released, it contains the fix for this crash.
You need to log in
before you can comment on or make changes to this bug.
Description
•