GNOME Bugzilla – Bug 120725
AccessibleEvent ref/unref queue corruption
Last modified: 2004-12-22 21:47:04 UTC
If an event is retained to be used later, in that case something goes wrong. I will attach a test file and it results.
Created attachment 19511 [details] [review] a simple test program which is trying to simulate gnopernicus behaviour
Created attachment 19512 [details] and it results
The test file can be copied in the at-spi/test directory with name simple-at.c.
I changed the priority and severity because this bug makes gnopernicus to crashe.
Seems that this bug is present specially for "mouse:abs" event, but I didn't test for other events.
Do I need to run anopther program to cause the crash in the test program or is having at-spi-registryd running sufficient?
You have to move mouse very quickly and in same time other events shoud be fired. To reproduce this bug I used gedit. I opened a menu and I moved mouse over the opened popup menu. I moved the mouse to open onother popups and over their children.
I am unable to reproduce this problem. Can you determine what the value of ref->ref_count is when the problem occurs, e.g. by running the test program in gdb. The error message suggests that there is some corruption in the hash table used to store accessible objects. Can you reproduce the problem with the file at-spi/cspi/spi_main compiled with DEBUG_OBJECTS defined. See line 36.
Yes, I can reproduce the bug. With DEBUG_OBJECTS compile flag is more simple to reproduce. Now all I have to do is to move the mouse. Also I modified spi_main.c file to show the values for "ref" pointer and for "ref->ref_count" variable.
Created attachment 19519 [details] the resuts with DEBUG_OBJECTS flag
yes, it looks like corruption of the internal event list, since the same address is getting allocated twice in a row.
Created attachment 19520 [details] Updated test program
Remus, Can you try with the updated test program?
I have tried this on a linux system and I cannot reproduce it there either. I find that the debug output from spi_main.c is different. As well as "allocated" and "releasing" messages I also see "returning cached" messages.
Padraig, In your patch a "{" is missing at line 48. The results are the same.
Created attachment 19522 [details] results with last proposed test program
correction - I don't actually see any evidence of queue corruption in the test results.
Remus, What did you do in gedit to get the results you appended for the test program? Sorry about the typo in the version Of the program I attached.
still can't reproduce...
Padraig, I tried mo make some actions which will generate a lot of mouse and, in same time alot of other events. I choose to move the mouse over menus, because in this way a lots of focus: events are generated for menu-items and for menus. So, I opened a menu, then I moved the mouse randomly over the menu-bar (to open other menus) and over then opened menu. Sometimes the crash occured immediatly, sometimes after more hardly, but, always I get a crash in less than 1 minute.
I have managed to get the crash to occur but I do not yet have a reproducible test case.
I am seeing cspi_object_return be called with accessible->on_loan set to TRUE and accessible->ref_count with value of 2. cspi_dup_ref is called and when it has returned accessible->ref_count has value 1. The reason for this is that cspi_object_unref has been called in the meantime and this has decremented the ref_count.
I think I have a scenario which could cause the problem: cspi_event calls cspi_object_return. This calls cspi_object_dup_ref. While waiting for this call to return cspi_event may be called again. If during this call the call calls AccessibleEvent_unref anddestroys the event which calls Accessible_unref on the event source. If this event source is the same accessible as that cspi_object_return was called the reference count for the accessible will be decremented when cspi_object_dup_ref returns.
Created attachment 19553 [details] [review] Proposed patch
Remus, Does the proposed patch cure the problem?
Padraig, With your patch I am not able to reproduce this bug anymore.
Bill, Do we want to request release team permission to apply this patch?
Yes - I will prepare the email if you like, or you are welcome to do it. - Bill
If you want to write the email that is fine by me. Are you satisfied with the patch?
Yes, the patch looks good (though I'd #undef the DEBUG_OBJECTS flag again ;-)
Patch committed to CVS HEAD.