Closed
Bug 410618
Opened 17 years ago
Closed 17 years ago
Crash when browsing Your Account at klm.com [@ nsRefPtr<nsListEventListener>::assign_assuming_AddRef]
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: cpuidle, Assigned: aaronlev)
References
()
Details
(Keywords: crash)
Crash Data
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010211 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010211 Minefield/3.0b3pre I've seen multiple crashes on the KLM.com frequent flyer site- even when restarting in safe mode. Crash reports have been submitted. Reproducible: Always Steps to Reproduce: 1. Open URL 2. Login 3. Browse around
Comment 1•17 years ago
|
||
Please provide the ids of the reports, see http://kb.mozillazine.org/Breakpad#Location_of_crash_reports for details. Also, can you test if the crash also occurs in Safe Mode ( http://kb.mozillazine.org/Safe_Mode ). If not please list which extensions you use, if any.
Reporter | ||
Comment 2•17 years ago
|
||
These are the Ids: Crash ID: bp-51c37f63-b9ec-11dc-8668-001a4bd43ef6 Crash ID: bp-8faac6ab-b9ec-11dc-91e6-001a4bd43e5c Crash ID: bp-ec02a2b3-b9ec-11dc-8dc2-001a4bd43e5c Crash ID: bp-3861f19e-b9ed-11dc-af51-001a4bd46e84 At least the some of them occured in safe mode.
Updated•17 years ago
|
Assignee: nobody → aaronleventhal
Component: General → Disability Access APIs
Keywords: crash
Product: Firefox → Core
QA Contact: general → accessibility-apis
Version: unspecified → Trunk
Comment 3•17 years ago
|
||
After logging in and browsing around for a while I'm not able to reproduce the crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010304 Minefield/3.0b3pre I tried browsing around both the German and English versions of the site, tabbing around the page at the URL and turning caret browsing on and moving around the page. I'm not familiar with accessibility bugs though so any advice on typical actions which would lead to nsAccessible::InvalidateChildren() being called would be appreciated. Andreas: Can you elaborate on step 3? Any specific pattern of browsing which leads to a crash, any specific page interaction, how long does it take before you crash and anything else you can add?
Reporter | ||
Comment 4•17 years ago
|
||
I believe I'm usually seing the bug when triggering an action that opens a new window (potentially an iframe). Funnily though I'm not using any accessibility features. Have seen such crashes on other bages, too, but not so frequent and not sure they happend in safe mode, too.
Reporter | ||
Comment 5•17 years ago
|
||
I keep seeing this bug- anything I could do to help? Crash ID: bp-35998df5-bca1-11dc-8f5d-001a4bd46e84
Assignee | ||
Updated•17 years ago
|
Blocks: fox3access
Flags: blocking1.9?
Comment 6•17 years ago
|
||
+'ing this and setting P3 priority. Anyone else able to reproduce this issue? Let's find out what's going on here.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Comment 7•17 years ago
|
||
(In reply to comment #5) > I keep seeing this bug- anything I could do to help? Let's start with the following: 1) Create a clean profile and see if it crashes. 2) Check to see if there are any system wide extensions installed (they should show in the add-ons manager, The only extension listed with a clean profile should be DOM-inspector). If there is an extension, then disable it, restart and try to crash. 3) Disable all plugins, restart and try to crash 4) Download latest nightly zip file, unzip to new folder and run with clean profile. Report back results from these steps. Any of them which lead to Firefox being more stable (and not crashing with the same stack signature) is a clue to the cause of the problem. Also while your doing this please take notes of actions which cause a crash. What is the URL of the current page when Fx crashed? Which link did you click on or other action did you take which lead to the crash? Do you have more than 1 tab or window open? After Fx crashes, restore the session and take the same action again - does it crash again? Good luck, I'll try out anything that looks like it might be a factor and see if it will reproduce the problem. btw, If any one needs log in details for the KLM site I can provide my test account details privately.
Keywords: qawanted
Reporter | ||
Comment 8•17 years ago
|
||
1) created new "clean" profile 2) started, checked tools->addons 3) have dom inspector and google gears isntalled (seems to be cross-profile) 4) right-click google gears (0.1.54.0)-> visit homepage -> crash Crash ID: bp-a7ee4891-bdcf-11dc-a828-001a4bd43ed6 5) disabled gogole gears, restarted 6) tools->addons->right-click google gears (now disabled)-> visit homepage -> no crash So- it's google gears. I guess it still shouldn't be crashing?
Comment 9•17 years ago
|
||
Thanks for testing this far. Google Gears and Minefield don't get along very well (see bug 392563). Your last crash is definitely because of google gears and doesn't explain your crashes on the klm site. With gears disabled in your clean profile does Minefield crash while browsing klm.com? if not, there's two possibilities that I can think of: 1) start installing extensions one by one and test for crashiness. If you have lots of extensions install half of them and test. No crash? install half of the rest and test, etc. While you're at it you might as well list your extensions. 2) Migrate files from your old profile to the new one and test each one. Likely candidates: *.sqlite files, localstore.rdf, prefs.js I'm guessing here, I really don't know what might have an affect on accessibility code. I realize that could tale quite a while, but whatever detail you can provide here will help.
Reporter | ||
Comment 10•17 years ago
|
||
No problem. 1) reported gears incident to bug 392563 you've mentioned as my test case might be simpler Can still reproduce original bug with gears disabled and clean profile, no additional extensions Crash ID: bp-89e5aee3-bdeb-11dc-84f5-001a4bd43e5c
Reporter | ||
Comment 11•17 years ago
|
||
Mhhm. Looking at latest crash report, mozilla site says "Error 404"- I guess it needs some processing time..
Reporter | ||
Comment 12•17 years ago
|
||
Was able to reproduce again, though steps are not identical, again clean profile, no gears, just dom inspector: Crash ID: bp-d9a68d97-bdec-11dc-84bf-001a4bd46e84 Steps (or similar): 1) goto www.klm.com 2) choose to navigate to German site (or automatic) 3) choose flying blue/ihr konto (your account) from top menu 4) login 5) choose ihr kontoauszug (your miles) ->usually crashes then 6) if not, keep surfing around the account page
Comment 13•17 years ago
|
||
Those crashes match the earlier ones. I tried to reproduce with those specific steps and no crash after browsing around a bit. There aren't any points registered in my account of course (it's just for testing) and the html associated with points on the account page may be what triggers it. So this leaves step 3 and 4 in comment 7. Good work so far.
Reporter | ||
Comment 14•17 years ago
|
||
Arie, not sure what you mean. Steps 3 and 4 in comment 7 should not apply as I was able to reproduce with clean profile and no addons?
Comment 15•17 years ago
|
||
Andreas, the general idea here is to try removing factors which might be causing the crash until there is no crash on your system, thereby identifying a possible cause. For step 3 you can use the add-ons manager to disable plugins in trunk builds. An other useful technique (which in this case might prove helpful by identifying code that is responsible) is a regression search - finding the last build which worked correctly. I generally go back one month at a time until I find a build that works and then use binary search (explained at http://wiki.mozilla.org/Calendar:QA_Home#Finding_a_Regression_Range_on_a_Bug )
Reporter | ||
Comment 16•17 years ago
|
||
Arie,
understood. What I mean is that your steps
>3) Disable all plugins, restart and try to crash
>4) Download latest nightly zip file, unzip to new folder and run with clean
profile.
are out of the picture as they don't contribute to the problem- it's reproducible without addons and present in latest nightly.
If I find the time I could try find a working one. I'm not sure its good though- as I don't see why it's only me experiencing this in the current nightlies?
Comment 17•17 years ago
|
||
Ah, I think I misunderstood your uncertainty. Plugins are different to extensions. Both are kinds of add-ons, but at the moment only extensions are disabled in safe mode. When you open the Add-ons window you'll see Extensions, Themes and Plugins.
Plugins normally show up in crash reports when they are causing problems and there isn't evidence of any in your stack traces. I did notice though that there's a dll loaded which I'm unfamiliar with. It's ItClient.dll which apparently belongs to Cognizance Identity and Access Management. Is there some way you can disable it and test? I admit this is pretty unlikely, but it is a difference between your and my machine.
unzip to new folder is to ensure old files from previous versions don't get in the way. If you always use the automatic updates then old versions of files which are no longer used can be left behind and cause problems.
> If I find the time I could try find a working one. I'm not sure its good
> though- as I don't see why it's only me experiencing this in the current
> nightlies?
Possibly not many people use klm.com with nightlies? This bug has been marked blocking so it's certainly worth investigating.
Severity: major → critical
Summary: [crash] Multiple crashes when browsing in safe mode → Crash when browsing Your Account at klm.com [@ nsRefPtr<nsListEventListener>::assign_assuming_AddRef]
Reporter | ||
Comment 18•17 years ago
|
||
1) could not get it to crash today- so either my environment or the nightly has changed 2) if I see another crash- I guess I could tell if the problem's back from looking at the crash report 3) the DLL is from an identity management software attached to laptops fingerprint sensor- something I can't get rid of Will update when I can reproduce again
Assignee | ||
Comment 19•17 years ago
|
||
Thanks Andreas, please keep us informed.
Assignee | ||
Comment 20•17 years ago
|
||
Have not heard back. Marking WORKSFORME. Please reopen if there is still a problem.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ nsRefPtr<nsListEventListener>::assign_assuming_AddRef]
You need to log in
before you can comment on or make changes to this bug.
Description
•