Hello, On 02/18/2016 08:13 PM, Kern Sibbald wrote: > At some point, I rewrote a good part of fstype, because one of the previous > authors wrote code that had more than the average number of bugs that we see > in > Bacula. > > However, I do not remember rewriting that code, and from what I see for both > Branch-7.2 and Branch-7.4 your analysis does not correspond to what I see. > That is the field ff_pkt->last_fstypename is a char[32], which means that the > pointer to ff_pkt->last_fstypename can never be NULL. The first byte of > ff_pkt->last_fstypename can be a zero, but that will not cause any problem. > > Perhaps if you could run the code and get a normal Bacula traceback, I can see > what is really going on. Also, if Bacula is crashing (i.e. a seg fault) then > it is most appropriate to file a bug report in addition to a note to this > list.
In the downloaded source tarball for 7.2.0, findable here: https://sourceforge.net/projects/bacula/files/bacula/7.2.0/bacula-7.2.0.tar.gz/download in src/findlib/find.h, the struct FF_PKT has the field: char *last_fstypename; /* cache last file system type name */ Here is the backtrace: (gdb) where #0 fstype (ff_pkt=0x66c258, fs=0x7ffff57a56a0 "\247\334\064Ҭ\336\351=3GrHy\345T\232\216\353\271\346\a\25 1\223r\032p\377|Ғ.\325\364\262.\273\372\061\035\243`)h!/\n\240\004݅\243\217QFg\35 4I\036\345\025\204}\332K", fslen=1000) at fstype.c:271 #1 0x00007ffff79bcb47 in accept_fstype (ff=ff@entry=0x66c258, dummy=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at find_one.c:140 #2 0x00007ffff79bd338 in find_one_file (jcr=0x66b858, ff_pkt=0x66c258, handle_file=0x7ffff79bbef0 <our_callback(JCR*, FF_PKT*, bool)>, fname=0x68bc28 "/", parent_device=18446744073709551615, top_level=true) at find_one.c:382 #3 0x00007ffff79bb3c7 in find_files (jcr=<optimized out>, ff=0x66c258, file_save=<optimized out>, plugin_save=0x410c70 <plugin_estimate(JCR*, FF_PKT*, bool)>) at find.c:176 #4 0x000000000040e4df in make_estimate (jcr=0x66b858) at estimate.c:50 #5 0x0000000000416348 in estimate_cmd (jcr=0x66b858) at job.c:664 #6 0x0000000000419531 in handle_director_request (dir=0x66a158) at job.c:314 #7 handle_connection_request (caller=0x66a158) at job.c:461 #8 0x00007ffff75906c5 in workq_server (arg=0x635b20) at workq.c:327 #9 0x00007ffff7337b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x00007ffff608630d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x0000000000000000 in ?? () I humbly submit that the Branch-7.2 source you inspected did not match the 7.2.0 released version. However, I looked in the same place in bacula 7.4.0 and found this: char last_fstypename[32]; /* cache last file system type name */ So, it seems to me that I should upgrade my bacula installation to 7.4.0. I'm not sure doing a bug report will help anything now that I see that the bug is already fixed. If you still think it is valuable for me to file a bug knowing all of this, I'll do so. Thank you! -pete ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
