GNOME Bugzilla – Bug 333678
atk-bridge panel crash on 64bit arch
Last modified: 2006-03-10 18:04:52 UTC
Steps to reproduce: 1. enable accessibility on a 64bit machine 2. try to log in 3. sit there watching the gnome splash screen do nothing Steps to reproduce in gdb: 1. log into failsafe xterm with accessibility enabled in gnome 2. start gnome-panel in gdb 3. watch it crash and burn Stack trace: 0x0000000000000000 in ?? ()
+ Trace 66741
Other information: It seems to be a recent release in Fedora rawhide as I have had accessibility on for awhile now with no problem. Atk version is 1.11.2. This only happens on 64 bit machines. I confirmed this on my laptop and a 64bit desktop machine. All 32bit machines work fine.
Crash does not occurs with 1.7.6; downgrading to 1.7.5 fixes it
Don't you mean it occurs with 1.7.6?
of course. 1.7.5 is fine, 1.7.6 crashes
What signal is being emitted in line #7 of the stack trace?
When you say "version 1.7.X", are you talking about at-spi? The bug is logged against ATK.... should we move it to at-spi then?
kjartan, the only diff between at-spi 1.7.6 and 1.7.5 is the diff for your leak fix.
Sorry, Bill. Yes it was at-spi. Downgrading that from 1.7.6 to 1.7.5 makes the crashes go away
Matthias, can you confirm that the problem is not seen on 32 bit arch? 1.7.5 has some big leaks, so it's a tough call as to what to release for gnome 2.14.0...
I can confirm that 1.7.5 works fine on all the 32bit machines I have used it on. I hope to find time today to investigate exactly which of the few leak fixes is causing the problem, that might give some hint as to what is actually going on...
Created attachment 60977 [details] [review] reverting this change fixes things for me
OW!, we can't revert that one, that's the whole data-freeing codepath!
Its your choice. That means no accessible desktop on x86-64
Matthias, it's not my choice; it's everybody's choice, I am only one person and I can't reproduce the problem and know almost nothing about it. I do know however that reverting the change as suggested in comment #10 would introduce massive leaks, so I doubt the release team would approve. Could there be something else about your 64 bit setup that explains the differences? For instance, is it multi-CPU? There may be problems lurking there. If you could try divide-and-conquer with the OTHER changes between 1.7.5 and 1.7.6 (note where the ._release flag is set in the at-spi event emission code), we might be able to narrow down the problem. I'd suggest that we create two patches, which revert different halves of the 'free-ing', to try and determine exactly which kinds of events are leading to your problem on free. If it's happening with ANY events, then that suggests some deep infrastructure, architectural, or ORB problem, which we're unlikely to fix for 2.14.0.
Oh, and Matthias: Make sure to update your version of gail. I think there may have been a gailtoplevel.c fix which is relevant.
I will look into this on Monday (I'm at home today and the x86_64 box is in the office...)
Thanks Matthias; best-case this will be fixed by updating gail. I'll look at preparing a pair of divide-and-conquer patches for investigation, in case the gail upgrade doesn't fix it.