Re: [Dri-users] Quake 1 & 3 failure(s) [savage]

[Felix <fx...@gm...>]

Am Donnerstag, den 03.02.2005, 02:46 +0100 schrieb danalien:
> On Thursdayen den 3 February 2005 02.08, danalien wrote:
>=20
> > 4. gdb=20
>=20
> oops, I ment
>=20
> 4. gdb 2>&1 | tee quake3.dump
>=20
> :-)  *d'ooh, if you wondered how I 'magically' created that dump in a VT,=
 that looses it's "buffer" (except what can fit on your screen) when you sw=
itch back and forth*
>=20
>=20
> On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote:
> >This is safe, even if you can't log in remotely.
>=20
> aha, but I think you could log it remotely =3DD

I can't reproduce your segfault with the Quake3 Demo. I even tried the
3D driver from a binary snapshot to exclude any local changes in my
source tree. Could be that your Q3 version does something different. Or
it could be problem specific to your compiler version. (gcc --version? I
haven't tried gcc-3.4 yet.)

Could you try quake3 with a savage_dri.so from a binary snapshot? You
don't need to install the snapshot. Just run quake3 like this (in bash):

LIBGL_DRIVERS_PATH=3D<path to savage_dri.so from snapshot> quake3

That savage_dri.so includes debug information. So if it still crashes
you can get a backtrace with line numbers. You could also inspect some
variable values to find out which one is causing trouble.

>=20
>=20
>   mkfifo quake3.dump
>=20
> (in an other ssh session or vt...what ever)
>   lftp ${myremotehosteI'vebookmarked}
>   put $PATH_TO_FILE/quake3.dump
>=20
> (back to 'main gdb' VT/ssh session...)
>   gdb 2>&1 | tee quake3.dump
>=20
> ... etc... jadda jadda jadda ...
>=20
>=20
> I haven't double-checked *this (prior to posting *this_msg),=20
> but I've played around with FIFO's before, and I'm fairly sure=20
> it'll work as I've scribbled it   =3D) *snaps his wipe at linux*

The FIFO doesn't help you if your console is locked and unusable. ;-)
That's what happens when the application crashes while holding the lock
and the debugger prevents that the application terminates and releases
the lock. You can try it if you like. Insert this code somewhere in
savageCreateContext (for example):

        LOCK_HARDWARE(imesa);
        assert(0);

Then run glxgears in the debugger locally. If you have a second computer
to log in from, you can kill the debugger. Otherwise you'll have to
reboot your computer.

--=20
| Felix K=FChling <fx...@gm...>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |