On Thu, Aug 04, 2005 at 03:19:05PM -0500, Jonathan Hayward wrote: > I'm scratching my head at how the pointer to the entry could be corrupted > between when the entry is created and when the signal handler reads the > value. The pointer is corrupt; on two runs I got values of 0x0/0xFF. I don't know how the value is stored. If you know the memory address where the pointer is stored, you can set a hardware watchpoint at that location. If it is passed as an argument, you probably don't have any other choice except tracking the code backwards. IIUC, the program crashes in a signal handler and the pointer is good before you are in the handler? Seems that you have some global pointer, which is a good candidate for a watchpoint. > If a buffer overflow had overwritten the pointer, would valgrind observe it? > If valgrind doesn't report problems before the segmentation violation, does > it mean that there probably isn't a memory error other than the segv? I'm not sure, you'll have to check the valgrind docs, they describe many scenarios that are (and that are not) catched. If your problem turns out to be an overflow, I'd like to hear whether valgrind helped in your case. I'm using 2.4 without any options, and it reports more overflows than I'd like to see :) . With kind regards, Baurzhan. _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
