>>>>> On Tue, 22 Jul 2008 10:10:33 +0200, Andrea Venturoli said:
> 
> Martin Simmons ha scritto:
> 
> > The best thing is to attach gdb to the running SD soon after it starts and 
> >  then use the commands 
> >  
> >  bt 
> >  info all 
> >  thread apply all bt 
> >  
> >  to generate a report when it crashes. 
> 
> Here it is:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x5de400 (LWP 100153)]
> 0x000000000040bb39 in acquire_device_for_read (dcr=0x5d0028) at 
> acquire.c:269
> 269              ASSERT(0);
> Current language:  auto; currently c++
> (gdb) up
> #1  0x000000000042c958 in mount_next_read_volume (dcr=0x5d0028) at 
> mount.c:790
> 790           if (!acquire_device_for_read(dcr)) {
> (gdb) do
> #0  0x000000000040bb39 in acquire_device_for_read (dcr=0x5d0028) at 
> acquire.c:269
> 269              ASSERT(0);
> (gdb) bt
> #0  0x000000000040bb39 in acquire_device_for_read (dcr=0x5d0028) at 
> acquire.c:269
> #1  0x000000000042c958 in mount_next_read_volume (dcr=0x5d0028) at 
> mount.c:790
> #2  0x000000000042f2ab in read_records (dcr=0x5d0028, record_cb=0x42ee40 
> <record_cb>, mount_cb=0x42c8b0 <mount_next_read_volume(DCR*)>) at 
> read_record.c:86
> #3  0x000000000042edd5 in do_read_data (jcr=0x5dec28) at read.c:86
> #4  0x0000000000423568 in read_data_cmd (jcr=0x5dec28) at fd_cmds.c:280
> #5  0x0000000000423099 in do_fd_commands (jcr=0x5dec28) at fd_cmds.c:165
> #6  0x0000000000422ee3 in run_job (jcr=0x5dec28) at fd_cmds.c:128
> #7  0x000000000042471c in run_cmd (jcr=0x5dec28) at job.c:210
> #8  0x000000000041d5bd in handle_connection_request (arg=0x5bca28) at 
> dircmd.c:232
> #9  0x0000000000461753 in workq_server (arg=0x58de00) at workq.c:357
> #10 0x00000008007d36e9 in pthread_create () from /lib/libpthread.so.2
> #11 0x00000008013eae04 in makecontext () from /lib/libc.so.6
> #12 0x0000000000000000 in ?? ()
> #13 0x00000000005de400 in ?? ()
> #14 0x00000000004614f0 in workq_remove () at workq.c:288
> ...
> I guess I should really file that bug report, but I'm lost wrt how to 
> describe this in details.

Yes, it looks like a bug.  The ASSERT(0) is forcing a crash, so I suspect this
part of the code is either unfinished or is never supposed to run.  The call
to ASSERT(0) is still in the development version.

I suggest putting the backtrace in your bug report, plus as much detail as
possible about your configuration and what triggers the crash.

__Martin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users