nvidia OpenGL and lib{thr,kse} related crash

[Daniel Eischen]

On Thu, 12 Jun 2003, Alexander Nedotsukov wrote:

> Daniel Eischen wrote:
> 
> >You can try this patch, but I don't really think that's the problem.
> >I think %gs is getting clobbered.  Apply patch to
> >libpthread/thread/thr_spec.c.
> >
> >  
> >
> Well, here is the result.
> 
> Breakpoint 1, _pthread_key_create (key=0x2813c220,
>     destructor=0x28122c90 <__nvsym15484+240>)
>     at /usr/src/lib/libpthread/thread/thr_spec.c:62
> 62              if (_thr_initial == NULL)
> (gdb) n
> 64              curthread = _get_curthread();
> (gdb) info registers
> eax            0x28237108       673411336
> ecx            0x0      0
> edx            0x0      0
> ebx            0x282374a4       673412260
> esp            0xbfbff998       0xbfbff998
> ebp            0xbfbff9b0       0xbfbff9b0
> esi            0x8059000        134582272
> edi            0x425    1061
> eip            0x2821fbb9       0x2821fbb9
> eflags         0x206    518
> cs             0x1f     31
> ss             0x2f     47
> ds             0x2f     47
> es             0x2f     47
> fs             0x2f     47
> gs             0x37     55

Yes, %gs is wrong.  For a single CPU system, it should be 0x8f.
For a dual CPU system, it could be either 0x8f or 0x97.  If
you breakpoint on libpthread_init() and look at %gs after it
finishes, you can see that it should be set to one of the
above values.  After that point, the threads library doesn't
touch %gs.

Something is clobbering %gs.  Either the kernel through compat
signal syscalls, or the nvidia openGL or drivers (are the drivers
kernel drivers, userland, or both?).

-- 
Dan Eischen