Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* how to debug this error by gdb?
@ 2009-05-11  2:35 明覺
  2009-05-11  3:12 ` Eli Zaretskii
  2009-05-11 17:21 ` Michael Snyder
  0 siblings, 2 replies; 6+ messages in thread
From: 明覺 @ 2009-05-11  2:35 UTC (permalink / raw)
  To: gdb

I'm debugging a application, for it crashes at line 660 of file
glxcmds.c, which is a file of mesa-7.4.1
here is the source code at which it crashes:
---------------------------------------------------------------------------------------
PUBLIC void glXWaitX(void)
{
  ......
           if (psc->driScreen->waitX != NULL)
[line 660]              (*psc->driScreen->waitX)(pdraw);
.....
}
---------------------------------------------------------------------------------------


and here is the gdb info:
---------------------------------------------------------------------------------------
(gdb) break glxcmds.c:660
Breakpoint 1 (glxcmds.c:660) pending.
(gdb) run
Breakpoint 1, glXWaitX () at glxcmds.c:660
(gdb) print psc->driScreen->waitX
$3 = (void (*)(__GLXDRIdrawable *)) 0x47206769666e6f63
(gdb) print *psc->driScreen->waitX
Cannot access memory at address
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
---------------------------------------------------------------------------------------

I think there are 2 possibilities:
(1) linking error, maybe psc->driScreen->waitX is linked to the wrong
address, then I'm wondering how could I further find the real memory
address of psc->driScreen->waitX? or,
(2) memory protection error, maybe 0x47206769666e6f63 is the correct
address of  psc->driScreen->waitX, but  it's cannot be accessed, then
what might be the cause?
could you help how to tell which is the correct possibility? and how
to solve it? thanks

-- 
我的操作系統是Gnu/Linux Debian-sid-amd64/gNewSense Gnome Mozilla
Gmail/Evolution Gtkmm/Clutter/Anjuta Scim Totem Pidgin.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: how to debug this error by gdb?
  2009-05-11  2:35 how to debug this error by gdb? 明覺
@ 2009-05-11  3:12 ` Eli Zaretskii
  2009-05-11  4:55   ` 明覺
  2009-05-11 17:21 ` Michael Snyder
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2009-05-11  3:12 UTC (permalink / raw)
  To: 明覺; +Cc: gdb

> Date: Mon, 11 May 2009 10:34:52 +0800
> From: =?ISO-2022-JP?B?GyRCTEBrNBsoQg==?= <shi.minjue@gmail.com>
> 
> ---------------------------------------------------------------------------------------
> PUBLIC void glXWaitX(void)
> {
>   ......
>            if (psc->driScreen->waitX != NULL)
> [line 660]              (*psc->driScreen->waitX)(pdraw);
> .....
> }
> ---------------------------------------------------------------------------------------
> 
> 
> and here is the gdb info:
> ---------------------------------------------------------------------------------------
> (gdb) break glxcmds.c:660
> Breakpoint 1 (glxcmds.c:660) pending.
> (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.

> (gdb) print *psc->driScreen->waitX
> Cannot access memory at address
> (gdb) step
> Program received signal SIGSEGV, Segmentation fault.

Right, because it's not NULL, but not a valid pointer, either.  Thus a
SIGSEGV.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: how to debug this error by gdb?
  2009-05-11  3:12 ` Eli Zaretskii
@ 2009-05-11  4:55   ` 明覺
  2009-05-11  6:24     ` Paul Pluzhnikov
  0 siblings, 1 reply; 6+ messages in thread
From: 明覺 @ 2009-05-11  4:55 UTC (permalink / raw)
  To: gdb

On Mon, May 11, 2009 at 11:11 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 11 May 2009 10:34:52 +0800
>> From: =?ISO-2022-JP?B?GyRCTEBrNBsoQg==?= <shi.minjue@gmail.com>
>>
>> ---------------------------------------------------------------------------------------
>> PUBLIC void glXWaitX(void)
>> {
>>   ......
>>            if (psc->driScreen->waitX != NULL)
>> [line 660]              (*psc->driScreen->waitX)(pdraw);
>> .....
>> }
>> ---------------------------------------------------------------------------------------
>>
>>
>> and here is the gdb info:
>> ---------------------------------------------------------------------------------------
>> (gdb) break glxcmds.c:660
>> Breakpoint 1 (glxcmds.c:660) pending.
>> (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
>
>> (gdb) print *psc->driScreen->waitX
>> Cannot access memory at address
>> (gdb) step
>> Program received signal SIGSEGV, Segmentation fault.
>
> Right, because it's not NULL, but not a valid pointer, either.  Thus a
> SIGSEGV.
>



-- 
我的操作系統是Gnu/Linux Debian-sid-amd64/gNewSense Gnome Mozilla
Gmail/Evolution Gtkmm/Clutter/Anjuta Scim Totem Pidgin.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: how to debug this error by gdb?
  2009-05-11  4:55   ` 明覺
@ 2009-05-11  6:24     ` Paul Pluzhnikov
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Pluzhnikov @ 2009-05-11  6:24 UTC (permalink / raw)
  To: 明覺; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: how to debug this error by gdb?
  2009-05-11  2:35 how to debug this error by gdb? 明覺
  2009-05-11  3:12 ` Eli Zaretskii
@ 2009-05-11 17:21 ` Michael Snyder
  2009-05-12 14:42   ` Frank Ch. Eigler
  1 sibling, 1 reply; 6+ messages in thread
From: Michael Snyder @ 2009-05-11 17:21 UTC (permalink / raw)
  To: 明覺; +Cc: gdb

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=Big5, Size: 1278 bytes --]

©úı wrote:
> I'm debugging a application, for it crashes at line 660 of file
> glxcmds.c, which is a file of mesa-7.4.1
> here is the source code at which it crashes:
> ---------------------------------------------------------------------------------------
> PUBLIC void glXWaitX(void)
> {
>   ......
>            if (psc->driScreen->waitX != NULL)
> [line 660]              (*psc->driScreen->waitX)(pdraw);
> .....
> }
> ---------------------------------------------------------------------------------------
> 
> 
> and here is the gdb info:
> ---------------------------------------------------------------------------------------
> (gdb) break glxcmds.c:660
> Breakpoint 1 (glxcmds.c:660) pending.
> (gdb) run
> Breakpoint 1, glXWaitX () at glxcmds.c:660
> (gdb) print psc->driScreen->waitX
> $3 = (void (*)(__GLXDRIdrawable *)) 0x47206769666e6f63
> (gdb) print *psc->driScreen->waitX
> Cannot access memory at address
> (gdb) step
> Program received signal SIGSEGV, Segmentation fault.
> ---------------------------------------------------------------------------------------

First you need to "print psc", to see if that pointer is valid.
Then print psc->driScreen, to see if that pointer is valid.
Only then can you examine something pointed to by psc->driScreen.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: how to debug this error by gdb?
  2009-05-11 17:21 ` Michael Snyder
@ 2009-05-12 14:42   ` Frank Ch. Eigler
  0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2009-05-12 14:42 UTC (permalink / raw)
  To: Michael Snyder; +Cc: =?Big5?B?qfrEsQ==?=, gdb

Michael Snyder <msnyder@vmware.com> writes:

> [...]
>> (gdb) print psc->driScreen->waitX
>> $3 = (void (*)(__GLXDRIdrawable *)) 0x47206769666e6f63

That value looks suspiciously like ascii: "G gifnoc".

- FChE


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-05-12 14:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-11  2:35 how to debug this error by gdb? 明覺
2009-05-11  3:12 ` Eli Zaretskii
2009-05-11  4:55   ` 明覺
2009-05-11  6:24     ` Paul Pluzhnikov
2009-05-11 17:21 ` Michael Snyder
2009-05-12 14:42   ` Frank Ch. Eigler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox