Last Comment Bug 701669 - crash when changing profile in profile manager
: crash when changing profile in profile manager
Status: VERIFIED FIXED
: crash, crashreportid, regression
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla11
Assigned To: alexander :surkov
:
Mentors:
Depends on: 706834
Blocks: 414302
  Show dependency treegraph
 
Reported: 2011-11-11 04:45 PST by Susanne Jaeger
Modified: 2011-12-01 08:48 PST (History)
10 users (show)
mounir: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
patch (4.34 KB, patch)
2011-11-21 05:16 PST, alexander :surkov
tbsaunde+mozbugs: review+
christian: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Susanne Jaeger 2011-11-11 04:45:13 PST
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 2 Philip Chee 2011-11-11 07:00:50 PST
Robert, any idea why the crash stat reports don't have any symbols?
Comment 3 Susanne Jaeger 2011-11-11 07:38:04 PST
(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 2011-11-11 11:32:57 PST
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 2011-11-11 14:07:26 PST
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) 2011-11-11 17:40:40 PST
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 2011-11-16 14:32:15 PST
(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 2011-11-17 02:56:29 PST
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 2011-11-18 03:43:52 PST
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 2011-11-18 04:44:21 PST
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 2011-11-18 05:16:07 PST
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 2011-11-18 05:50:38 PST
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) 2011-11-18 06:20:12 PST
Trevor, any idea on this?
Comment 14 Trevor Saunders (:tbsaunde) 2011-11-20 02:10:39 PST
(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 2011-11-20 02:23:19 PST
(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) 2011-11-20 03:26:40 PST
(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) 2011-11-20 04:37:00 PST
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) 2011-11-20 04:45:09 PST
(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.
Comment 19 alexander :surkov 2011-11-20 23:46:37 PST
(In reply to Trevor Saunders (:tbsaunde) from comment #17)

> (this is a regression from 673958)

no, regression from bug 414302
Comment 20 alexander :surkov 2011-11-21 05:16:15 PST
Created attachment 575834 [details] [diff] [review]
patch
Comment 21 Trevor Saunders (:tbsaunde) 2011-11-23 22:32:42 PST
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 2011-11-23 22:52:48 PST
(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 2011-11-24 20:45:47 PST
landed on inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/2c2d56cc5808
Comment 24 Mounir Lamouri (:mounir) 2011-11-25 02:30:10 PST
https://hg.mozilla.org/mozilla-central/rev/2c2d56cc5808
Comment 25 alexander :surkov 2011-11-25 02:52:02 PST
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) 2011-11-29 01:01:42 PST
Landed on Alexander's behalf in Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/63829f362db8
Comment 27 alexander :surkov 2011-11-29 02:33:34 PST
Thanks, Marco.
Comment 28 Susanne Jaeger 2011-11-30 00:08:18 PST
crashs are gone after update - thanks
Comment 29 Marco Zehe (:MarcoZ) 2011-11-30 01:35:51 PST
Setting verified as per comment #28. Thanks, Susanne, for reporting the issue and verifying the fix!

Note You need to log in before you can comment on or make changes to this bug.