[Bacula-users] fstype.c and find.h
Yes, I was working from the Branch-7.2 in the repo, and it had a bunch
of later changes. When I backed up to the 7.2.0 release, it is as you say.
The new code in Branch-7.4 does not contain a pointer so the particular
problem you are currently having probably no longer exists. However, I
see from your output that you are running an estimate command. That
command uses a lot of code that is different from the main backup code
as it is only an "estimate" so it is possible that there will be some
I rewrote large parts of fstype.c (not all) in Branch-7.4, so I
recommend that you start by upgrading to 7.4.0. If the problem still
persists, which should not happen, or another one shows up, please
On 02/19/2016 12:45 PM, Peter Keller wrote:
> 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
>> 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, 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
>> 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
> In the downloaded source tarball for 7.2.0, findable here:
> 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,
> 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
> #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; /* 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!
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!
Bacula-users mailing list