Re: [Bacula-devel] Possible bug in SD,

[Kern S. <ke...@si...>]

Hello Arno,

Please open a bug report.  There are two things that I would like to see:

1. The exact sequence of commands that lead to the problem

2. Debug output set at say 400 on the SD during the period that mtx misbehaves 
up to the point the SD blows it self up.

3. a traceback (stack dump) produced by gdb.  The gdb dump should be in the 
working directory.

Best regards,

Kern


On Thursday 15 October 2009 09:33:21 Arno Lehmann wrote:
> Hi,
>
> I just was presented with a SD failure in an assert.
>
> Backups were running, and I changed volumes on an autochanger. After
> the new tapes were loaded, I did the usualy 'update slots' ceremony:
>
> *update slots scan storage=QuantumDLT drive=0
> Connecting to Storage daemon QuantumDLT at gnom:9103 ...
> 3306 Issuing autochanger "slots" command.
> Device "QuantumDLT" has 0 slots.
> No slots in changer to scan.
>
> *** The above happens most of the time at the first try - I guess it's
> a slight mtx problem - I can reproduce it, but mtx seems to always
> work correctly on the second consecutive call.
>
> *update slots scan storage=QuantumDLT drive=0
> Connecting to Storage daemon QuantumDLT at gnom:9103 ...
> 3306 Issuing autochanger "slots" command.
> Device "QuantumDLT" has 7 slots.
> Connecting to Storage daemon QuantumDLT at gnom:9103 ...
> 3306 Issuing autochanger "list" command.
> Connecting to Storage daemon QuantumDLT at gnom:9103 ...
> 3301 Issuing autochanger "loaded? drive 0" command.
> 3302 Autochanger "loaded? drive 0", result: nothing loaded.
> 3304 Issuing autochanger "load slot 1, drive 0" command.
> 3305 Autochanger "load slot 1, drive 0", status is OK.
> Jmsg Job=*System* type=4 level=1255590981 gnom-sd: ERROR in
> block.c:946 Failed ASSERT: dev->is_open()
>
> Consequently, the SD killed itself at that time.
>
> I got a bactrace in the working directory (but it looks shorten than
> usual...):
>
> Attempt to dump locks
> threadid=0xb2fbcb90 max=1 current=-1
> threadid=0xb57c1b90 max=3 current=0
>     lock=0x809b4a0 state=G rwlock.c:236
> threadid=0xb6ff9b90 max=2 current=0
>     lock=0xb7ed28f0 state=G watchdog.c:307
> threadid=0xb78a48e0 max=0 current=-1
> threadid=0xb78a48e0 max=2 current=-1
> threadid=0xb7864b90 max=0 current=-1
> Attempt to dump current JCRs
> JCR=0x80bfd30 JobId=11490 name=CopyElf2DLT.2009-10-13_13.43.47_08
> JobStatus=R
>          use_count=1
>          JobType=c JobLevel=F
>          sched_time=14-Oct-2009 21:19 start_time=01-Jan-1970 01:00
>          end_time=01-Jan-1970 01:00 wait_time=01-Jan-1970 01:00
>          dequeing=0
>          db=(nil) db_batch=(nil) batch_started=0
> JCR=0x80f98d0 JobId=0 name=*System* JobStatus=C
>          use_count=1
>          JobType=I JobLevel=
>          sched_time=15-Oct-2009 09:14 start_time=01-Jan-1970 01:00
>          end_time=01-Jan-1970 01:00 wait_time=01-Jan-1970 01:00
>          dequeing=0
>          db=(nil) db_batch=(nil) batch_started=0
> Attempt to dump plugins
>
> *** nothing after this.
>
> The version running is gnom-sd Version: 3.1.4 (28 September 2009)
> i686-pc-linux-gnu suse 11.1 from git, pulled and compiled on Sep. 30.
>
> I doubt I can reproduce the above as I did the same stuff quite a few
> times without any problems, but perhaps the failing assertion is worth
> looking at.
>
> Cheers,
>
> Arno