On Thu, 03 Feb 2005 17:41:07 +0530, Mohan Kumar S said: > coredump. dbx shows gtk internal functions. i cant figure out where & > why it happens.Please help > The program does coredump, which is not reprodusable. > when i debug using dbx, "where" > the most frequent one is this > > g_type_check_instance > > can anyone please tell, where there could be a problem > > (dbx)where > > [1] g_type_check_instance_is_a(0x6a678, 0x50a10, 0xfefce024, 0x7800, > 0xff264cc4, 0x7a28), at 0xfefce02c The single most important thing to remember for debugging this sort of thing is that the coredump quite likely didn't actually happen anywhere near where the bug is. What's probably happened is that some *other* code, somewhere else in the program, has overwritten data that g_type_check_instance() then used. The most common causes of these sort of errors: 1) Going off the end of an array or string (storing into foo[50]; when it's declared as 'int foo[50];', or strcat() or sprintf() writing more chars than you allocated). 2) Abuse of a pointer - using the same value as a 'struct *foo' in one routine and 'struct *bar' in another. This is a lot harder to do without the compiler whinging at you in recent C that uses ANSI function prototypes, but used to be quite common in K&R C. 3) Using a pointer in one routine after you've done a free() of it elsewhere (causing indigestion for whoever got an malloc() there after the free(). 4) Returning a pointer to a location on the returning function's stack. How to debug this: 1) Get a clean compile. Compile with 'gcc -Wall' and fix up the stuff it complains about. 2) If your system has 'valgrind' installed, try using that - it will track down a lot of memory-use errors.
Attachment:
pgpHPSTmzSQ8U.pgp
Description: PGP signature