This is the mail archive of the
mailing list for the glibc project.
Re: Please help me understand this stack trace
- From: Ángel González <keisial at gmail dot com>
- To: Bryan Ischo <bryan at ischo dot com>
- Cc: libc-help <libc-help at sourceware dot org>
- Date: Tue, 05 Jun 2012 22:29:58 +0200
- Subject: Re: Please help me understand this stack trace
- References: <4FCE5FA0.firstname.lastname@example.org>
On 05/06/12 21:36, Bryan Ischo wrote:
> Hi there, I am experiencing an occasional deadlock that I believe is
> due to an Nvidia driver problem. My program attempts to do a
> fork()/exec() sequence from a thread that does not have a GLX
> context. As far as I know this is perfectly legal but some sort of
> trickery in Nvidia's OpenGL library is somehow intercepting the fork
> and then causing a deadlock. Here is the stack trace in the process
> that deadlocks (portions above the fork() call ommitted):
> Thread 1 (Thread 0x7f217f9fb7c0 (LWP 1402)):
> #0 0x00007f217d7a400c in __lll_lock_wait () from /lib/libpthread.so.0
> #1 0x00007f217d79fee7 in _L_lock_560 () from /lib/libpthread.so.0
> #2 0x00007f217d79fd79 in pthread_mutex_lock () from /lib/libpthread.so.0
> #3 0x00007f217e80d9ec in ?? () from /usr/lib/libGL.so.1
> #4 0x00007f217ad975e4 in ?? () from /usr/lib/libnvidia-glcore.so.295.53
> #5 0x00007f217e7efe2c in ?? () from /usr/lib/libGL.so.1
> #6 0x00007f217e7f060e in ?? () from /usr/lib/libGL.so.1
> #7 0x00007f217da67d56 in fork () from /lib/libc.so.6
> Note that this is in the child process; apparently fork() has already
> succeeded in cloning the parent process into a child, but after that
> it calls into some unnamed function in /usr/lib/libGL.so.1.
> I simply cannot understand how libc's fork() function is calling into
> the OpenGL library. By what mechanism might this be occurring? Is
> there some kind of fork hook that I am unaware of that NVidia is using
> to register a callback during fork()? I suspected pthread_atfork()
> and I attempted unsuccessfully to "override" pthread_atfork by
> creating my own dummy implementation thereof, building a shared object
> library out of it, and using LD_PRELOAD to force my version to be
> used. Since I have never done this before, I can't be certain that I
> did everything correctly; my pthread_atfork() function was never
> called in any case, and this attempt did not fix the problem.
> Does anyone have any creative ideas on how I can prevent glibc fork()
> from calling into the NVidia OpenGL library?
> I am running glibc version 2.15 on an AMD64 architecture system (Intel
> E5540). Nvidia driver version is 295.53.
> uname -a:
> Linux <redacted> 3.3.7-1-ARCH #1 SMP PREEMPT Tue May 22 00:26:26 CEST
> 2012 x86_64 GNU/Linux
> Thank you and best wishes!
nvidia driver is a binary one :(
Still, I see the string __register_atfork at libglx.so.295.53 and
libGL.so.295.53 files. You might have luck overriding that symbol.
Another idea would be rebuilding the libgl package with debug symbols
(yes, that one is open source), so that you get at least a better backtrace.