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
