>>>>> On Tue, 12 Jul 2011 16:15:59 +0200 (CEST), Pierre Bourgin said:
> 
> ----- "Martin Simmons" <martin AT lispworks DOT com> wrote:
> 
> > >>>>> On Mon, 11 Jul 2011 11:42:35 +0200 (CEST), Pierre Bourgin said:
> > > 
> > > Hello,
> > > 
> > > I have installed bacula 5.0.3 on a CentOS 5.4 x86_64 system (RPM
> > x86_64 rebuilt from source) and it's working great since a year.
> > > 
> > > After a mistake I mad, I need to restore my catalog.
> > > So I tried to use bextract in order to restore a 51 MB file from a
> > volume-disk file of 20GB.
> > > bextract hangs a lot: 100% CPU used, no I/O wait at all.
> > > After several minutes of run, I stopped it without any success:
> > restored file with created, but empty.
> > > 
> > > Since I really need this file, I've tried the 32bit version of
> > bextract on the same system: worked fine !
> > > 
> > > I've tried to debug it by the use of strace, but I'm not clever
> > enough to find anything usefull in these outputs.
> > > (please find the strace files attached to this email)
> > > 
> > > So I don't know if it's a bug from the packaging or a bextract bug
> > related to 64bit platform ?
> > > 
> > > If someone has a clue ...
> > 
> > To find out where is it looping, attach gdb to the process when it is
> > hanging
> > (use gdb -p $pidofbextract) and then issue the gdb commands
> > 
> > thread apply all bt
> > detach
> > quit
> > 
> > Do this a few times to get an idea of how it changes.
> 
> Hello,
> 
> Thanks for your help.
> 
> Once bextract has started, I've launched a batched gdb once per minute with 
> the gdb commands you provided.
> gdb then always shows a similar output like this (see below):
> - adresses of the Thread 1 stack are always the same
> - addresss of the Thread 2 stack: only #0 and #1 are different 
> (inflate_table() and inflate()), 
> - Thread 1: sometime call to inflate_table() does not appears
> 
> # while [ 1 ]; do gdb -p `pgrep bextract` -x gdb.show-backtrace.commands  ; 
> sleep 4; done
> 
> ============== gdb sample output ==========================================
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Attaching to process 10007
> Reading symbols from /usr/sbin/bextract...(no debugging symbols found)...done.
> Reading symbols from /lib64/libacl.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libacl.so.1
> ....
> Reading symbols from /lib64/libpthread.so.0...done.
> [Thread debugging using libthread_db enabled]
> [New Thread 0x2b7ee0469850 (LWP 10007)]
> [New Thread 0x40af4940 (LWP 10008)]
> Loaded symbols for /lib64/libpthread.so.0
> ....
> Loaded symbols for /lib64/libselinux.so.1
> Reading symbols from /lib64/libsepol.so.1...done.
> Loaded symbols for /lib64/libsepol.so.1
> 0x00002b7ee025a106 in inflate_table () from /usr/lib64/libz.so.1
> 
> Thread 2 (Thread 0x40af4940 (LWP 10008)):
> #0  0x0000003a7620dfe1 in nanosleep () from /lib64/libpthread.so.0
> #1  0x0000003e32a1425b in bmicrosleep (sec=30, usec=0) at bsys.c:63
> #2  0x0000003e32a40efb in check_deadlock () at lockmgr.c:571
> #3  0x0000003a76206617 in start_thread () from /lib64/libpthread.so.0
> #4  0x0000003a75ad3c2d in clone () from /lib64/libc.so.6
> 
> Thread 1 (Thread 0x2b7ee0469850 (LWP 10007)):
> #0  0x00002b7ee025a106 in inflate_table () from /usr/lib64/libz.so.1
> #1  0x00002b7ee0257537 in inflate () from /usr/lib64/libz.so.1
> #2  0x00002b7ee0252396 in uncompress () from /usr/lib64/libz.so.1
> #3  0x0000000000406b6f in record_cb ()
> #4  0x0000000000425298 in read_records ()
> #5  0x0000000000406438 in main ()
> ============== gdb sample output ==========================================
> 
> so trouble related to zlib and its use by bextract ?

Nicely done.  It looks like bug 1703:

http://bugs.bacula.org/view.php?id=1703


> Another thing: 
> bextract and bconsole do not have the same entry point for libz.so, and only 
> for that one;
> does it mean they do not use libz the same way ?

By "entry point", do you mean the number shown after the filename in the
output of ldd?  That is the base address in memory and isn't important.


> > If you have debuginfo packages for bacula, then install them first.
> 
> these packages definitions are not provided by bacula.spec from the 
> bacula-5.0.3 sources. 
> Would you have such a .spec file to generate them ?

Don't worry about it -- some rpm build configurations generate them
automatically, but maybe yours doesn't.

__Martin

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users