Re: Bug in GLib, libglade, libc??

[tomas tuxteam de]

On Tue, Aug 15, 2006 at 12:57:06AM -0300, Fabricio Rocha wrote:
> Thank you very much, Yeti and Samuel, for your replies!
[...]
>       I have a suspicion from my lack of practice in C: a module of my 
> program uses a structured type which must contain, as its last member, a 
> dynamic list of strings, i.e., pointers to gchars (**list). Sometimes I 
> need to fill only the first string, and sometimes I will need more than 
> one string. So I suspect that each attempt to set a value for one of 
> these pointers cause a serious corruption of other areas of the program, 
> like the GTK stuff in memory. I have tried to assign values to this 
> (these) pointers both with g_strdup and by creating a local, initialized 
> array and assigning its address to the pointer. Neither worked. Do you 
> think I should give each pointer a malloc'd space somewhere in memory, 
> and then strcpy the value to this pointer?

This one indeed looks suspicious, so your hunch might be well sounded
;-)

As far as C cis concerned, gchar **list is just a pointer to a pointer
to a char (or a pointer to a char array -- C does not make a difference
here. See a good C reference for this. I'd recommend Kerninghan &
Ritchies classic book which albeit old is extremely clear in those
basics. For a quick lookup, this
<ttp://www.cs.cf.ac.uk/Dave/C/node10.html#SECTION001030000000000000000>
has some details on pointers, arrays and all that).

The upshot is, you'd better make sure that **list points to whatever
makes sense in your context. But we'll never know for sure if you don't
show us the code :-)

>       By the way, I have read a lot of GDB and Valgrind docs, and still could 
> not get anything from them. [...]

Gdb and valgrind are powerful tools, but you'll have to have a good
working model of what is going on inside your program to make sense of
them. For example, gdb is quite at a loss with stray pointer problems.
With those, the fault pokes a hole somewhere which might well trip up
the application much later, at a seemingly unrelated place (e.g. when
ten layers of functions have returned, stumbling over the corrupt stack
area or when the memory allocator trees to free something at a place
where memory has been corrupted). Go find that then :-)

HTH
-- tomás