Yes, I agree.  I have now fixed the problems you pointed out and committed it.  Thanks.

On 05/21/2018 07:05 PM, Martin Simmons wrote:
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?), where
ua->jcr->pool->cleaning_prefix is NULL, so strlen is called on NULL.

The size of size_t usually matches the size of pointers, so it will be twice
the size of int on most 64-bit systems.  Casting it to int sounds safe here to
me.

__Martin


On Mon, 21 May 2018 17:37:39 +0200, Kern Sibbald said:
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 knowledge are
always the same size.  However, it probably would be better to cast it
to an int.

Best regards,

Kern


On 05/21/2018 02:04 PM, Martin Simmons wrote:
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.  There are loads of the these in Bacula.

__Martin



On Mon, 21 May 2018 13:39:20 +0200, Kern Sibbald said:
Hello,

      It looks to me like it might be a compiler bug.  Try compiling
        Bacula with -O0  (minus capital-o zero).

      Also you could set debug level at 110 in the Director and turn on
        trace.  Then we might see something in the trace file.

      Best regards,

      Kern





    On 05/20/2018 05:15 PM, Rasmus Linden
        wrote:

cite="mid:632e6317-7e21-4a8f-b21c-fb044db9a...@gmail.com"> Hey All !!


I have a strange issue, I hope some of you can help
          me with. I am currently running bacula version: 9.0.7, recently
          migrated from mysql to postgres.
        Everything is working as expected, except when i try
          to table a tape and stick it in our scratch pool, bacula-dir
          crashes with a bang !
        I have set the debug level to 10, and pasted the
          traceback.
        The last thing happening before the crash, according
          to the stack is a sql query :


SELECT MediaId,VolumeName,VolJobs,VolFiles,VolBlocks,VolBytes,VolABytes,VolHoleBytes,VolHoles,VolMounts,VolErrors,VolWrites,MaxVolBytes,VolCapacityBytes,MediaType,VolStatus,PoolId,VolRetention,VolUseDuration,MaxVolJ class="">
obs,MaxVolFiles,Recycle,Slot,FirstWritten,LastWritten,InChanger,EndFile,EndBlock,VolType,VolParts,VolCloudParts,LastPartBytes,LabelType,LabelDate,StorageId,Enabled,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId
           class="">
          ,VolReadTime,VolWriteTime,ActionOnPurge,CacheRetention FROM
          Media WHERE VolumeName=‘B00110L6'


I have tried running the query by hand, and it does
          not fail *screenshot from pgadmin attached.


If i label the volume and stick it into a none
          scratch pool, it completes with no error.


Any suggestion on how to fix is mostly appreciated !


All the best


Ras



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to