Hi Kern,
My guess is that ua->jcr->pool was initialized (by set_jcr_defaults?) to
points to Rasmus's ProjectsArchive pool, so ua->jcr->pool->cleaning_prefix is
non-NULL on entry to is_cleaning_tape (until he edited the resource).
Then ua->jcr->pool is set to a different pool (maybe Scratch?),
Hello Martin,
If accesses ua->jcr->pool->cleaning_prefix before setting it, then why
doesn't the test for NULL at the beginning either seg fault or simply
return?
The format in my code at line 999 seems to me to match the arguments
correctly in that a size_t and an int to the best of my
The cleaning prefix looks OK to me.
The disass output from gdb would still be useful.
__Martin
> On Mon, 21 May 2018 13:30:37 +0200, Rasmus Linden said:
>
> Martin you rock !
>
> I took the cleaning tape definition out of the pool , and now i can label to
> the scratch pool.
> Thanks so
Yes, possibly.
OTOH, I think is_cleaning_tape might have a bug: it reads
ua->jcr->pool->cleaning_prefix before setting ua->jcr->pool.
Also, the format string in the debug message doesn't match the args (strlen
does not return an int) so the debug output might cause more
problems/confusion.
Martin you rock !
I took the cleaning tape definition out of the pool , and now i can label to
the scratch pool.
Thanks so much.
I wonder if i misunderstood the cleaning prefix key.
All the best, and thanks again
Ras
POOL BEFORE EDIT
Pool {
Name = ProjectsArchive
Pool Type = Backup
The traceback suggests some problem in the is_cleaning_tape function.
It might be useful to do
gdb /opt/bacula/bin/bacula-dir
disass is_cleaning_tape
__Martin
> On Sun, 20 May 2018 17:15:40 +0200, Rasmus Linden said:
>
> Hey All !!
>
> I have a strange issue, I hope some of you can help
