Re: how to debug this error by gdb?

[Paul Pluzhnikov <ppluzhnikov@google.com>]

2009/5/10 明覺 <shi.minjue@gmail.com>:
> On Mon, May 11, 2009 at 11:11 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>>> (gdb) run
>>> Breakpoint 1, glXWaitX () at glxcmds.c:660
>>> (gdb) print psc->driScreen->waitX
>>> $3 = (void (*)(__GLXDRIdrawable *)) 0x47206769666e6f63
>>                                      ^^^^^^^^^^^^^^^^^^
>> This looks like ASCII text to me ("config G", little-endian).  So I'd
>> try to see if some code that runs before this place could overflow
>> some buffer with plain text, and part of that text spilled into this
>> pointer.
> I do not understand, could give some advice about what to do? thanks

The 'psc->driScreen' points to some structure, containing waitX element.
That element was likely initialized to NULL at some point in execution,
and may have been initialized to point to some function later on.

Eli's conjecture (which I think is very likely correct) is that later
still, some other code did a strcpy(x, y), where 'x' is at a lower memory
address than psc->driScreen, and *does not have enough space* for string
'y', thus causing a buffer overflow. Further, string 'y' contained
"... config G..." in it, and these characters happened to overwrite
whatever bytes psc->driScreen->waitX used to contain. When you proceed
to call "config G" as if it were a legal pointer, SIGSEGV results.

The simplest way to track this down is probably to stop the
application when 'psc->driScreen->waitX' is initalized, and set a
watchpoint on it:

  (gdb) watch *(int **)&psc->driScreen->waitX

If Eli's conjecture is true, above watchpoint will fire inside strcpy
(or some similar libc function) exactly when waitX is being corrupted.

An alternative (that I believe is also very likely) is that
psc->driScreen is simply dangling. That is harder to isolate with GDB.

If you run your program under Valgrind (which I strongly advise you to
do), it should be able to tell you exactly what the problem is for
either of the above guesses.

Cheers,
-- 
Paul Pluzhnikov