Hey again, If this is any help I did manage to get pdp and Gem loaded with the LD_ASSUME_KERNEL=2.4.19 by renaming the tls libnvidia so LD could not find it. So the trace I now get is: Program received signal SIGTERM, Terminated. ---Type <return> to continue, or q <return> to quit--- [Switching to Thread 16384 (LWP 8356)] 0x4013c124 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) bt #0 0x4013c124 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x4013af29 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x40138d08 in pthread_join () from /lib/libpthread.so.0 #3 0x412bc440 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux which is very similar to the one I got without LD_ASSUME_KERNEL: Program received signal SIGTERM, Terminated. [Switching to Thread 1076308992 (LWP 8379)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4012f288 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x42a92440 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux I changed to pdp since its crashing the same way on the same function but has a much simpler structure. Maybe this is slightly enlightening. b. Joerg Bashir wrote:
Mmm... odd, in the name "libnvidia-tls" is that part of the nvidia package, is there a non-tls version? On Tue, 20 Sep 2005, B. Bogart wrote:Hi Joerg, I tried seeting this variable but PD then fails to load the Gem object due to: Gem.pd_linux: libnvidia-tls.so.1 cannot handle TLS data I also tried LD_ASSUME_KERNEL as 2.4.0 and 2.4.20 with the same results. I also thought I could recompile the nvidia module with LD_ASSUME_KERNEL=2.4.19 but PD still refused to load the object. I also recompiled the Gem object with that variable set, still the same results as above, Gem will not load with LD_ASSUME_KERNEL set to 2.4.x What is TLS anyway?? Thanks for the suggestion. b. Joerg Bashir wrote:Well, you can try http://people.redhat.com/drepper/assumekernel.html LD_ASSUME_KERNEL=2.4.19 That will avoid NPTL and should use the libc in /lib instead of /lib/tls See how that works. It could be that pd/gem tries to do multiple thread_joins which will fail except in old pthreads. On Tue, 20 Sep 2005, B. Bogart wrote:Hello, Ok well what happens is I try and set the v4l channel, then the application freezes (pd/gem). I manually kill the application and look at the trace and its sitting in pthread_join() just before the syscall. pthread_join is all I have to go on, how do I check what threads are running? How do I see what thread in what code is actually causing the freeze? I've asked on many lists so far and no one is suggesting how to get more information on what is actually happening (even the authors of the software). So if pthread_join is not the issue then please let me know how I can figure out what is the issue. Thanks! b. Daniel Jacobowitz wrote:On Tue, Sep 20, 2005 at 01:23:12PM -0400, B. Bogart wrote:Hello all, I tried on debian-user without any luck, perhaps someone on here will have an idea how I can further debug this issue. Sorry for anyone who got tired of seeing this on debian-user. I'm running a stock sarge machine with the 32bit 2.6.8 kernel on a AMD64 3200+ machine. I'm using some unstable and demudi packages for media applications, in particular pure-data (PD). Problem I'm having is that PD crashes when I try and use v4l2. Actually there is no fault, but PD hangs. I traced it down to the use of pthread_join() which is where the code hangs. (I've been doing a backtrace after manually killing the application)Why do you think it's pthread_join's fault? pthread_join will wait for a thread to complete. Is the thread being joined still running?
Attachment:
signature.asc
Description: OpenPGP digital signature