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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
