Re: [Tsemgr-linux] edit phonebook entry crash and possible fix?

[Sebastian S. <s.s...@ci...>]

Hi Michael!

> excuse me for hacking away at your code, but I found it most annoying
> that tsemgr 0.07 and CVS hung in the following condition:
> 
> Step 1: load phone book from SE T610 over bluetooth
> Step 2: edit an entry
> Step 3: save entry
> Step 4: edit another entry
> <program hangs>
[snip]


> we apear to be stuck off in malloc and realloc land off of a gtk call,
> and this gtk call seems to be gtk_entry_with_new_max_length.  Other than
> this being a depreciated GTK call, I can't find anyone ever having this
> particular problem.
> 
> Trudging along further, I decided to run tsemgr, albeit very
> sloooowwwlllyyyy  under valgrind.  Valgrind finds all sorts of nifty
> problems......  but aside from this, it prints an interesting message
> relating to editPBentry after clicking save on the first edit dialog
> (step 3 above):
> 
> ==1176== Invalid free() / delete / delete[]
> ==1176==    at 0x4015E64C: free (in /usr/lib/valgrind/valgrind.so)
> ==1176==    by 0x403BE262: g_free (in /usr/lib/libglib-1.2.so.0.0.10)
> ==1176==    by 0x40285E62: gtk_entry_finalize (in
> /usr/lib/libgtk-1.2.so.0.9.1)
> ==1176==    by 0x402D193B: gtk_object_unref (in
> /usr/lib/libgtk-1.2.so.0.9.1)
> ==1176==    Address 0x41CB06A8 is 0 bytes inside a block of size 8
> free'd
> ==1176==    at 0x4015E64C: free (in /usr/lib/valgrind/valgrind.so)
> ==1176==    by 0x403BE262: g_free (in /usr/lib/libglib-1.2.so.0.0.10)
> ==1176==    by 0x805703B: editPBentry (in /root/src/tsemgr-0.07/tsemgr)
> ==1176==    by 0x402BA105: gtk_marshal_NONE__NONE (in
> /usr/lib/libgtk-1.2.so.0.9.1)
> 
> 
> This seems bad.  Upon looking at the code in editPBentry, we free name
> and number which are return results from gtk_entry_get_text.  The
> documentation I found said that under no condition were you to attempt
> to free the pointers returned from gtk_entry_get_text..... sure enough
> at line 1113 and 1114 of callbacks.c i see the following:
> 
>   g_free (number);
>   g_free (name);
> 
> Here ends my understanding of what is going on.  all that I know is that
> commenting out these free calls enables me to edit multiple entries in a
> row without the apparent malloc hang... maybe we're freeing memory that
> we shouldn't, as the gtk manual suggests?  I don't know, but I thought
> that I would point this out... and maybe this isn't a good solution...
> hopefully this will point to a real bug somewhere else...

First of all thank you for your extensive debugging and sorry for the
long time it took me to reply (my internet connection was gone for about
a month).

I'll check this, fix it and add you to the list of contributers.
But you should be aware of the fact that I've stopped development on the
current codebase of tsemgr.
I'm currently working on a complete rewrite of tsemgr which will use
GTK+-2.2.
Maybe you're interested in maintaining the "old" tsemgr code?


Regards,
Sebastian

PS: Thank you again for your help. This is what projects like tsemgr
need!