Crash when editing nickname

Amit Chaudhuri amit.k.chaudhuri at gmail.com
Mon Jan 21 02:18:56 PST 2013


Happy to look at it.

Dirk - did you also say you preferred "Ok" to "Apply"?




On Mon, Jan 21, 2013 at 9:21 AM, Henrik Brautaset Aronsen <
subsurface at henrik.synth.no> wrote:

> I can confirm that Dirk's patch works.  Amit, maybe you could do a couple
> of additional improvements:
>
> - Disable the Apply button until there is something to apply
> - Don't close the nickname window after deleting a nickname
>
> Cheers,
> Henrik
>
> Amit Chaudhuri wrote:
>
>> Hi Henrik,
>>
>> thanks for catching.
>>
>> Interestingly, I can't reproduce exactly the same way, but was able to
>> crash if I simply fail to edit anything and go straight for "Apply".
>>
>> Dirk,
>>
>> the fix you mention does catch it.  I had that covered in a call to
>> "clear down" function from edit_dc_nicknames in an earlier version, but I
>> "rationalised" it out somewhere along the way.  Problem is (as you clearly
>> worked out) the dereference of holdnicknames when it points to null.  This
>> happens if no edits take place.
>> The code path back through cell_edited_cb is where holdnickname list
>> entries are created.
>>
>> Regards,
>>
>> Amit
>>
>>
>> On Sat, Jan 19, 2013 at 10:05 PM, Dirk Hohndel <dirk at hohndel.org <mailto:
>> dirk at hohndel.org>> wrote:
>>
>>     Henrik Brautaset Aronsen <subsurface at henrik.synth.no
>>     <mailto:subsurface at henrik.**synth.no <subsurface at henrik.synth.no>>>
>> writes:
>>
>>     > 1) Open the nickname list (must have 2 or more entries)
>>     > 2) Delete one of the entries (The list window closes?!)
>>     > 3) Re-open the nickname list
>>     > 4) Edit a nickname and press Apply
>>     >
>>     > *BOOM*
>>     >
>>     > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>>     > 0   subsurface                        0x0000000103adb303
>>     > edit_dc_nicknames + 2227 (gtk-gui.c:1274)
>>     > 1   libgobject-2.0.0.dylib            0x000000010474ebc4
>>     > g_closure_invoke + 308
>>
>>     This seems to fix it.
>>
>>     Amit, can you confirm that this is a smart way to address the
>>     issue (I'm
>>     not 100% certain how the flow is supposed to work in this case -
>>     but it
>>     seems to work with this change)
>>
>>     Thanks
>>
>>     /D
>>
>>     diff --git a/gtk-gui.c b/gtk-gui.c
>>     index 7a8f10c..29a77b6 100644
>>     --- a/gtk-gui.c
>>     +++ b/gtk-gui.c
>>     @@ -1271,7 +1271,7 @@ static void edit_dc_nicknames(GtkWidget *w,
>>     gpointer data)
>>                             }
>>                             gtk_widget_destroy(confirm);
>>                     }
>>     -               if (res == GTK_RESPONSE_APPLY &&
>>     holdnicknames->model != NULL ) {
>>     +               if (res == GTK_RESPONSE_APPLY && holdnicknames &&
>>     holdnicknames->model != NULL ) {
>>                             struct device_info * walk = holdnicknames;
>>                             struct device_info * release = holdnicknames;
>>                             struct device_info * track =
>>     holdnicknames->next;
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130121/cec63f24/attachment.html>


More information about the subsurface mailing list