701669 - crash when changing profile in profile manager

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Susanne Jaeger]

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

[Philip Chee]

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.

Comment 2

[Philip Chee]

Robert, any idea why the crash stat reports don't have any symbols?

Comment 3

[Susanne Jaeger]

(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

[Philip Chee]

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.

Comment 5

[Susanne Jaeger]

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.

Comment 6

[Justin Wood (:Callek)]

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

[Robert Kaiser]

(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?

Comment 8

[Susanne Jaeger]

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

Comment 9

[Susanne Jaeger]

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

[Robert Kaiser]

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.

Comment 11

[Susanne Jaeger]

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

[Robert Kaiser]

The crash is in accessibility code, so I'll move the bug there and hope someone from that team can help a bit more.

Comment 13

[Marco Zehe (:MarcoZ)]

Trevor, any idea on this?

Comment 14

[Trevor Saunders (:tbsaunde)]

(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

Comment 15

[Susanne Jaeger]

(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

Comment 16

[Trevor Saunders (:tbsaunde)]

(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)

Comment 17

[Trevor Saunders (:tbsaunde)]

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)

Comment 18

[Trevor Saunders (:tbsaunde)]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 19

[alexander :surkov (:asurkov)]

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

> (this is a regression from 673958)

no, regression from bug 414302

Comment 20

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 21

[Trevor Saunders (:tbsaunde)]

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.

Comment 22

[alexander :surkov (:asurkov)]

(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

Comment 23

[alexander :surkov (:asurkov)]

landed on inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/2c2d56cc5808

Comment 24

[Mounir Lamouri (:mounir)]

https://hg.mozilla.org/mozilla-central/rev/2c2d56cc5808

Comment 25

[alexander :surkov (:asurkov)]

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).

Comment 26

[Marco Zehe (:MarcoZ)]

Landed on Alexander's behalf in Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/63829f362db8

Comment 27

[alexander :surkov (:asurkov)]

Thanks, Marco.

Comment 28

[Susanne Jaeger]

crashs are gone after update - thanks

Comment 29

[Marco Zehe (:MarcoZ)]

Setting verified as per comment #28. Thanks, Susanne, for reporting the issue and verifying the fix!