GNOME Bugzilla – Bug 442860
Segmentation fault in glade_id_allocator_release()
Last modified: 2008-03-11 00:04:28 UTC
Steps to reproduce: Steps to Reproduce: 1.open the sample.glade file (see attachment) 2.doubleclick "window" in Inspector 3.click on the "." (period) button to select it 4.change the name of this button to "num_00" (Properties, tab General) 5.select "table" in Inspector 6.change number of rows to 5 (new row appears below others) 7.right-click on the "0" (zero) button, select "copy" 8.right-click on empty space below "0" button, select paste 9.right-click "." button, select "cut" Segmentation fault Stack trace: Program received signal SIGSEGV, Segmentation fault. 0x00002b90ca4ad5bf in glade_id_allocator_release (allocator=0x111f7c0, id=4294967295) at glade-id-allocator.c:142 142 allocator->data[id >> 5] |= 1 << (id & 31); (gdb) bt
+ Trace 137206
Other information: The steps to reproduce are very specific, I know. Naming the "." button something else, like "num_99" or "bla" doesn't cause a segfault. Also, cut/pasting the "." without first copy/pasting another button doesn't segfault. Copy/pasting the "1" button into the empty space below the "0", followed by the cut/paste of the ".", does segfault, but copy/pasting the "=" button into the empty space below the "0", followed by the cut/paste of the ".", does not segfault. If there's any more info I could provide, please let me know.
Created attachment 89172 [details] sample.glade use this file to reproduce the steps outlined in the bug report
Thankyou so much, we've been noticing crashes in the id allocator (and I'm aware of some rework that needed to be done) but we havent had anything specifically reproducable till now... I'm going to take a closer look, thanks again.
*** Bug 412047 has been marked as a duplicate of this bug. ***
*** Bug 438974 has been marked as a duplicate of this bug. ***
This crash occurs due to two factors... Firstly, consider this debug output (following repro instructions): ./glade3 DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 1; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 2; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 3; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 4; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 5; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 6; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 7; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 8; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 9; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 10; DEBUG: (glade_id_allocator_allocate) allocator: 0x12e5c90; id: 11; DEBUG: (glade_project_release_widget_name) widget-name: num_00; DEBUG: (glade_id_allocator_release) allocator: 0x12e5c90; id: 0; Segmentation fault (core dumped) Factor 1: if you pass `0' as the second parameter to `glade_id_allocator_release (GladeIDAllocator* allocator, guint id)', you will get a segmentation fault. In glade_id_allocator_release(): Since we have that `id' is unsigned and id equals 0, the op `id--' results in a large number such as `3252352235'. This is promptly followed by a segmentation fault because of the out-of-bounds array access `data[id>>5]'. The correct solution is to ensure that glade_id_allocator_release() sticks to it's contract as defined by the parameter types it declares as acceptable. It must accept `0' as a parameter. Factor 2: From observing the debug output, notice that we attempt to release the id `0' without having allocated it first. This is invalid. It's also wrong that we are dealing with an `0' id in the first place. I believe it's the case that id must be greater than 0.
*** Bug 462769 has been marked as a duplicate of this bug. ***
Ok this bug is fixed in svn, overall widget name policing should be better all around.