On Sun, 26 Jan 2003 15:37:03 +0000
[EMAIL PROTECTED] wrote:

> > Could you reproduce a lockup with a GL app running in a remote debugger
> > session. When the system is locked up you press Ctrl+C in the debugger,
> > get backtrace with the "bt" command and send it to the list.
> I tried to do this from a remote machine and locally, and both times, I 
> get errors like:
> 
> **********************************************
> 
> $ gdb
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-slackware-linux".
> (gdb) exec-file /usr/local/lib/xscreensaver/endgame
> (gdb) set args -display :0
> (gdb) run
> Starting program: /usr/local/lib/xscreensaver/endgame -display :0
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
> warning: shared library handler failed to enable breakpoint

I've never seen this. Somehow gdb and ld.so don't seem to play together
as they should. I'm afraid this way you won't get a meaningful backtrace
of the radeon driver.

> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x404fc600 in ?? ()
> (gdb) quit

As Arkadi wrote this is normal, just continue.

> The program is running.  Exit anyway? (y or n) y
> $
> 
> **********************************************
> 
> A window is created for the hack to run, but nothing ever appears.
> 
> It appears to me that I need to compile endgame (and/or other GL hacks) 
> with debugging information. I don't know how to do this, though. If you 
> could direct me to some information about how I would go about it, I'd 
> much appreciate it.

This may not even help. The radeon driver is always loaded dynamically.
As the error message above indicates this means that you won't be able
to debug it. I don't think compiling xscreensaver yourself with debug
info will help.

> > About the flickering when running endgame on the root window, I could
> > reproduce that too, even with TCL enabled. It looks to me like it is
> > using a single buffered visual in that case. Curiously this doesn't
> > happen when xscreensaver runs endgame on the root window.
> 
> I was reading a document later about graphics coding and it mentioned 
> that erasing the image you wanted to move, and then redrawing it would 
> produce flicker and the solution to this was double-buffering and it 
> reminded me of the flickering I see when running the GL hacks. I tried, 
> and when having xscreensaver run the hacks in the root window, I get 
> flickering. Curiouser and curiouser.

Allright, when I turn off TCL it flickers even if xscreensaver runs it.
I'll look into this one.

> 
> Thanks.
> 
> -Andy

Felix

               __\|/__    ___     ___     ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
  [EMAIL PROTECTED]    >o<__/   \___/   \___/        at the same time!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to