Date: Thu, 12 Jun 2003 01:59:48 +0900
From: Alexander Nedotsukov <bland@mail.ru>
To: Daniel Eischen <eischen@pcnet.com>
Cc: "Matthew N. Dodd" <mdodd@freebsd.org>
Subject: Re: nvidia OpenGL and lib{thr,kse} related crash
Message-ID: <3EE76004.7060606@mail.ru>
In-Reply-To: <Pine.GSO.4.10.10306111208260.13761-100000@pcnet5.pcnet.com>
References: <Pine.GSO.4.10.10306111208260.13761-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: >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. > Right. It's 0x8f in my case. > >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?). > > > Blah. I got the bastard. It's nvidia's libGL.so.5. Just a few calls before fatal pthrerad_key_create() execution steps throgh __nvsym15480() ... 0x281229ed <__nvsym15480+233>: push %eax 0x281229ee <__nvsym15480+234>: push $0x1 0x281229f0 <__nvsym15480+236>: mov $0xa5,%eax 0x281229f5 <__nvsym15480+241>: push %eax 0x281229f6 <__nvsym15480+242>: int $0x80 0x281229f8 <__nvsym15480+244>: add $0xc,%esp 0x281229fb <__nvsym15480+247>: cmp $0xffffffff,%eax 0x281229fe <__nvsym15480+250>: jge 0x28122a05 <__nvsym15480+257> 0x28122a00 <__nvsym15480+252>: mov $0xffffffff,%eax 0x28122a05 <__nvsym15480+257>: cmp $0x2d,%eax 0x28122a08 <__nvsym15480+260>: jne 0x28122a1a <__nvsym15480+278> 0x28122a0a <__nvsym15480+262>: add $0xfffffff4,%esp 0x28122a0d <__nvsym15480+265>: push $0x28139b80 0x28122a12 <__nvsym15480+270>: call 0x281184a0 <__nvsym15149> 0x28122a17 <__nvsym15480+275>: add $0x10,%esp 0x28122a1a <__nvsym15480+278>: mov 0x4(%edi),%eax 0x28122a1d <__nvsym15480+281>: add $0x6,%eax 0x28122a20 <__nvsym15480+284>: shl $0x3,%eax 0x28122a23 <__nvsym15480+287>: or $0x7,%al >>0x28122a25 <__nvsym15480+289>: mov %eax,%gs 0x28122a27 <__nvsym15480+291>: mov %edi,0x8(%ebp) 0x28122a2a <__nvsym15480+294>: mov %ebp,0x2813c230 0x28122a30 <__nvsym15480+300>: pop %ebx 0x28122a31 <__nvsym15480+301>: pop %esi 0x28122a32 <__nvsym15480+302>: pop %edi 0x28122a33 <__nvsym15480+303>: pop %ebp 0x28122a34 <__nvsym15480+304>: add $0x2c,%esp 0x28122a37 <__nvsym15480+307>: ret Does some one know any nvidia developer to point them out on this fact? All the best, Alexander.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EE76004.7060606>