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. __MartinOn 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. __MartinHello,On Mon, 21 May 2018 13:39:20 +0200, Kern Sibbald said: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 helpme 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 doesnot fail *screenshot from pgadmin attached.If i label the volume and stick it into a nonescratch pool, it completes with no error.Any suggestion on how to fix is mostly appreciated !All the bestRas
------------------------------------------------------------------------------ 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