Hello Volker,

Please remind me what Linux distro and what kernel version you are using.

If you are on a 2.4 kernel, then the problem is 99% for sure the /lib/tls bug 
that is mentioned in the manual.  The manual suggests two solutions -- I 
prefer to zap the /lib/tls library by moving it to /lib/tls-broken

If this is on a 2.6 kernel, you will need to recompile with debug symbols 
turned on and re-run it.  The backtrace you got looks a bit strange to me 
because there are only 3 threads reported, and generally in the Directory, 
there are a lot more threads 5-10 depending on what is going on.

On Friday 22 July 2005 15:00, Volker Sauer wrote:
> On So, 17 Jul 2005, Kern Sibbald <[EMAIL PROTECTED]> wrote:
> > You could try running it under the debugger without debugging symbols.
> > This is not ideal, but if it is an internal deadlock, I should be able to
> > see it. That might avoid you having to spend the time to rebuild it. 
> > Unfortunately without manually running it under the debugger and getting
> > some form of traceback, there isn't much I can do to resolve it.
>
> Hello Kern,
>
> I ran bacula-dir under the debugger without debugging symbols.
> i seems to be a problem with threads:
>
> [.......]
> [New Thread 1136855984 (LWP 16684)]
> [New Thread 1145244592 (LWP 16685)]
> [New Thread 1170418608 (LWP 30231)]
>
>   Program received signal SIGINT, Interrupt.
>   [Switching to Thread 1078024992 (LWP 31494)]
>   0x401a7436 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
>   (gdb)  thread apply all bt
>
>   Thread 107 (Thread 1170418608 (LWP 30231)):
>   #0  0x401a5295 in pthread_cond_wait@@GLIBC_2.3.2 () from
>   /lib/tls/libpthread.so.0
>   #1  0x080959fc in ?? ()
>   #2  0x0808c8d2 in ?? ()
>   #3  0x0808bd56 in ?? ()
>   #4  0x0807458c in ?? ()
>   #5  0x0807468e in ?? ()
>   #6  0x0809e4db in ?? ()
>   #7  0x401a2b63 in start_thread () from /lib/tls/libpthread.so.0
>   #8  0x4037418a in clone () from /lib/tls/libc.so.6
>
>   Thread 106 (Thread 1145244592 (LWP 16685)):
>   #0  0x401a7436 in __lll_mutex_lock_wait () from
>   /lib/tls/libpthread.so.0
>   #1  0x401a4893 in _L_mutex_lock_26 () from /lib/tls/libpthread.so.0
>   #2  0x080c5b80 in optind ()
>   #3  0x00000000 in ?? ()
>   #4  0x00000000 in ?? ()
>   #5  0x00000001 in ?? ()
>   #6  0x00000001 in ?? ()
>   #7  0x00000000 in ?? ()
>   #8  0x44430ad8 in ?? ()
>   #9  0x0805b982 in ?? ()
>   Previous frame identical to this frame (corrupt stack?)
>   #0  0x401a7436 in __lll_mutex_lock_wait () from
>   /lib/tls/libpthread.so.0
>   (gdb)
>
>
> Does this help?
>
> Maybe to problem occured when I set Max Client Jobs = 2 on a specific
> client. I'll try again with 1 concurrent job!
>
> Regards
> Volker

-- 
Best regards,

Kern

  (">
  /\
  V_V


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to