crash when changing profile in profile manager

VERIFIED FIXED in Firefox 10

Status

()

Core
Disability Access APIs
--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Susanne Jaeger, Assigned: surkov)

Tracking

({crash, crashreportid, regression})

Trunk
mozilla11
crash, crashreportid, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox10+ fixed)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a2) Gecko/20111111 Firefox/10.0a2 SeaMonkey/2.7a2
Build ID: 20111111013001

Steps to reproduce:

select an existing profile in profile manager. Creating a new profile and starting this one, or deleting active profile and start previous from list works. 


Actual results:

SeaMonkey crashes. Last crash-ID: 6f8aad60-ee31-4fc8-9980-eca0f2111111


Expected results:

start with selected profile

Comment 1

6 years ago
https://crash-stats.mozilla.com/report/index/6f8aad60-ee31-4fc8-9980-eca0f2111111
https://crash-stats.mozilla.com/report/index/c236e56e-a196-4e9e-bfe3-74b0b2111111

No symbols available. That makes things difficult.
Crash Signature: [@ libxul.so@0x10bad4d ]
Keywords: crash, crashreportid

Comment 2

6 years ago
Robert, any idea why the crash stat reports don't have any symbols?
(Reporter)

Comment 3

6 years ago
(In reply to Philip Chee from comment #1)
> https://crash-stats.mozilla.com/report/index/6f8aad60-ee31-4fc8-9980-
> eca0f2111111
> https://crash-stats.mozilla.com/report/index/c236e56e-a196-4e9e-bfe3-
> 74b0b2111111
> 
> No symbols available. That makes things difficult.

Can I change / influence this in any way?

Comment 4

6 years ago
Is this a self build or something you downloaded from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/?

The files there should all have the necessary symbols uploaded to the Mozilla crash-stats server.
(Reporter)

Comment 5

6 years ago
first crash happened with a build from http://www.seamonkey-project.org/dev/aurora after automatic update. Later on I tested directly with 2.7a2 from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-aurora/
both under Debian Squeeze 64bit

but there must be some unknown side effect: I can't reproduce the crash on my notebook that runs Squeeze 64 bit too.
Ok few things, first Aurora symbols (for linux) are being uploaded: 
removed `93bdcf8d94f3f5d1481262e27ee5c3c10d106e6b-seamonkey-2.7a2.en-US.linux-i686.crashreporter-symbols-full.zip'
/usr/local/bin/post-symbol-upload.py "/mnt/netapp/breakpad/symbols_sea//seamonkey-2.7a2-Linux-20111110013001-symbols.txt"
Symbol transfer completed
make[1]: Leaving directory `/builds/slave/comm-aurora-lnx-ntly/build/objdir/mozilla'

However it *seems* like its not uploading Linux64 symbols.

I do see your processor listed as AMD64, so that is one thing that seems to be on my plate as a separate (release engineering) bug.

As far as your crash in particular, unfortunately there is little we can see about these crashes until I can do that.

Comment 7

6 years ago
(In reply to Philip Chee from comment #2)
> Robert, any idea why the crash stat reports don't have any symbols?

OK, I think we cleared that up and fixed it for current builds, right?
(Reporter)

Comment 8

6 years ago
here is a new crash report from just updated version: https://crash-stats.mozilla.com/report/index/bp-48d2356b-edf7-4623-b004-0d0952111117
(Reporter)

Comment 9

6 years ago
I just noticed that I get the same crash when I try to change some preferences. As soon as I select an entry in the category tree of the preferences window Seamonkey crashes. Using the arrow to expand entrys works, but selecting anything not. This also happens with a new profile.
https://crash-stats.mozilla.com/report/index/bp-3b4c4049-348f-4863-8a5f-961882111118

Comment 10

6 years ago
This is a pretty rare crash apparently, but if you find some way to reliably reproduce it, preferably even with Firefox, we could get someone to look at it.
https://crash-stats.mozilla.com/report/list?signature=nsAccessibleWrap%3A%3AFirePlatformEvent has more occurrences in the last week.
Crash Signature: [@ libxul.so@0x10bad4d ] → [@ libxul.so@0x10bad4d ] [@ nsAccessibleWrap::FirePlatformEvent ]
(Reporter)

Comment 11

6 years ago
on this system I can reproduce it reliably. Even with Firefox i686 
https://crash-stats.mozilla.com/report/index/bp-a98d8c1f-9aff-4a45-a7af-8916e2111118 
I just had to look for a treelike structure in some menu - in firefox it was show all bookmarks and select something in the left part of the window.

But I'm lacking ideas how to find out which soft or hardware-requirements outside Mozilla are needed to trigger it.

Comment 12

6 years ago
The crash is in accessibility code, so I'll move the bug there and hope someone from that team can help a bit more.
Status: UNCONFIRMED → NEW
Component: Startup & Profiles → Disability Access APIs
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: profile-manager → accessibility-apis
Trevor, any idea on this?
(In reply to Marco Zehe (:MarcoZ) from comment #13)
> Trevor, any idea on this?

NO, the stack seems a bit odd. nsAccessibleWrap::HandleAccEvent() should be between frames 0 and 1, and nsAccessibleWrap::FirePlatformEvent() clearly has a wrong  line number since that line is several hundred lines below that methods definition.  I expect the first of these is just TCO and to be expected, but I don't have an explanation for the bad line number.  I can see if I can reproduce this.

Susanne, would you be able to get a back trace in gdb with debug symbols?

I suppose another posibility is that this is a dup of 697339, which we should really try to understand better at some point
(Reporter)

Comment 15

6 years ago
(In reply to Trevor Saunders (:tbsaunde) from comment #14)
 
> Susanne, would you be able to get a back trace in gdb with debug symbols?

I could try if s.o. can give me some hint where to look und what to do. 
given mailadress is valid and read
(In reply to Susanne Jaeger from comment #15)
> (In reply to Trevor Saunders (:tbsaunde) from comment #14)
>  
> > Susanne, would you be able to get a back trace in gdb with debug symbols?
> 
> I could try if s.o. can give me some hint where to look und what to do. 
> given mailadress is valid and read

actually, nvm, I was able to reproduce this.  so far I found we're violating an invariant somewhere, here is the info for the top frame.

(gdb) bt full
#0  nsAccessibleWrap::FirePlatformEvent (this=0x7fffd4d80a00, aEvent=<optimized out>)
    at /home/tbsaunde/src/mozilla/accessible/src/atk/nsAccessibleWrap.cpp:1099
        selChangeEvent = 0x0
        accessible = 0x7fffd4d80a00
        type = 14
        atkObj = 0x7fffd5965740
        accWrap = <optimized out>
#1  0x00007ffff5e0e961 in nsEventShell::FireEvent (aEvent=0x7fffdcac91c0)
So, in nsRootAccessible.cpp about line 490-500 we have nsEventShell::FireEvent(Selection_WIthin, ...) and nsEventShell::FireEvent(SELECTION, ...) of course these will create AccEvent  objects not AccSeleChange objects, and the down cast will fail.  I'm pretty sure the SELECTION one is wrong, and consider the SELECTION_WITHIN one to be of high  dubiousity.

(this is a regression from 673958)
Blocks: 673958
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10)
> This is a pretty rare crash apparently, but if you find some way to reliably
> reproduce it, preferably even with Firefox, we could get someone to look at
> it.
> https://crash-stats.mozilla.com/report/
> list?signature=nsAccessibleWrap%3A%3AFirePlatformEvent has more occurrences
> in the last week.

My guess for the low frequency is the low percentage of users with accessibility enabled.    I suspect that when accessibility is enabled this actually breaks a lot of things badly.  I suspect forcing accessibility to be enabled by setting GNOME_ACCESIBILITY=1 in your environment and then running $gecko_app and changing selections in a xul tree will  do it.
(Assignee)

Comment 19

6 years ago
(In reply to Trevor Saunders (:tbsaunde) from comment #17)

> (this is a regression from 673958)

no, regression from bug 414302
Blocks: 414302
No longer blocks: 673958
Keywords: regression
(Assignee)

Comment 20

6 years ago
Created attachment 575834 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #575834 - Flags: review?(trev.saunders)
(Assignee)

Updated

6 years ago
Severity: normal → critical
Comment on attachment 575834 [details] [diff] [review]
patch


>-    NS_ASSERTION(treeAcc,
>-                 "Accessible for xul:tree isn't nsXULTreeAccessible.");

why don't you want to assert this?

> #ifdef MOZ_XUL
>   // If it's a tree element, need the currently selected item
>   if (isTree) {

you could use treeAcc here and get rid of isTree.

>   }
> #endif
> 
> #ifdef MOZ_XUL

same ifdef, you don't need 2 of them.

on the other hand maybe it makes more sense to just do a more general cleanup / reorg of this chunk of code at somepoint in the future.
Attachment #575834 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 22

6 years ago
(In reply to Trevor Saunders (:tbsaunde) from comment #21)

> >-    NS_ASSERTION(treeAcc,
> >-                 "Accessible for xul:tree isn't nsXULTreeAccessible.");
> 
> why don't you want to assert this?

that's depended on installed extensions or product, for example, if someone change binding for xul tree so xul tree gets new semantics. We shouldn't really assert.

> you could use treeAcc here and get rid of isTree.
> same ifdef, you don't need 2 of them.

done
(Assignee)

Comment 23

6 years ago
landed on inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/2c2d56cc5808
https://hg.mozilla.org/mozilla-central/rev/2c2d56cc5808
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
OS: Linux → All
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Flags: in-testsuite?
(Assignee)

Comment 25

6 years ago
Comment on attachment 575834 [details] [diff] [review]
patch

regression from Firefox 10, crash every time when user operates with XUL trees on Linux (both Firefox and Thunderbird affected).
Attachment #575834 - Flags: approval-mozilla-aurora?

Updated

6 years ago
Attachment #575834 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

6 years ago
status-firefox10: --- → affected
tracking-firefox10: --- → +
Landed on Alexander's behalf in Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/63829f362db8
status-firefox10: affected → fixed
(Assignee)

Comment 27

6 years ago
Thanks, Marco.
(Reporter)

Comment 28

6 years ago
crashs are gone after update - thanks
Setting verified as per comment #28. Thanks, Susanne, for reporting the issue and verifying the fix!
Status: RESOLVED → VERIFIED
(Assignee)

Updated

6 years ago
Depends on: 706834
You need to log in before you can comment on or make changes to this bug.