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
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
