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)

x86
Windows XP
defect

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
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.
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.
Assignee: nobody → aaronleventhal
Component: General → Disability Access APIs
Keywords: crash
Product: Firefox → Core
QA Contact: general → accessibility-apis
Version: unspecified → Trunk
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?
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.
I keep seeing this bug- anything I could do to help?

Crash ID: bp-35998df5-bca1-11dc-8f5d-001a4bd46e84
Blocks: fox3access
Flags: blocking1.9?
+'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
(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
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?
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.
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
Mhhm. Looking at latest crash report, mozilla site says "Error 404"- I guess it needs some processing time..
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
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.
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?
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 )
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?
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]
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
Thanks Andreas, please keep us informed.
Have not heard back. Marking WORKSFORME. Please reopen if there is still a problem.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsRefPtr<nsListEventListener>::assign_assuming_AddRef]
You need to log in before you can comment on or make changes to this bug.