From owner-freebsd-threads@FreeBSD.ORG Wed Jun 11 09:59:52 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D8D837B401; Wed, 11 Jun 2003 09:59:52 -0700 (PDT) Received: from bbnest.dyndns.org (r251052.ap.plala.or.jp [220.108.251.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BA8743FE3; Wed, 11 Jun 2003 09:59:51 -0700 (PDT) (envelope-from bland@mail.ru) Received: from mail.ru (bland@localhost [127.0.0.1]) by bbnest.dyndns.org (8.12.9/8.12.9) with ESMTP id h5BGxmae000888; Thu, 12 Jun 2003 01:59:49 +0900 (JST) (envelope-from bland@mail.ru) Message-ID: <3EE76004.7060606@mail.ru> Date: Thu, 12 Jun 2003 01:59:48 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030512 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org cc: "Matthew N. Dodd" Subject: Re: nvidia OpenGL and lib{thr,kse} related crash X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 16:59:52 -0000 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.