Bacula-users

Re: [Bacula-users] onefs query

2016-02-18 21:19:01
Subject: Re: [Bacula-users] onefs query
From: Kern Sibbald <kern AT sibbald DOT com>
To: Peter Keller <pkeller AT sift DOT net>, bacula-users AT lists.sourceforge DOT net
Date: Fri, 19 Feb 2016 12:13:44 +1000
Hello,

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.

Best regards,
Kern

On 02/19/2016 08:01 AM, Peter Keller wrote:
> Hello,
>
> I read the 7.2.0 codes and changed my fstype in the Options to just
> be the ones that are actually supported and that I use.
> However, it still faulted.
>
> I tracked down the segfault to this line (bacula 7.2.0) fstype.c:271:
>
>
> bstrncpy(ff_pkt->last_fstypename, fstype, sizeof(ff_pkt->last_fstypename));
>
>
> The enclosing function is bool fstype(FF_PKT *ff_pkt, char *fs, int fslen).
>
> The problem is that ff_pkt->last_fstypename is NULL, but the char* pointer
> of the field is N bytes wide:
>
> (gdb) p ff_pkt->last_fstypename
> $9 = 0x0
> (gdb) p sizeof(ff_pkt->last_fstypename)
> $10 = 8
>
> So, this code is just wrong. It may have been right once if FF_PKT's
> last_fstypename has been something like a char[32] type, because then the
> sizeof would be have been meaningful.
>
> It seems that the field last_fstypename is not being handled very well in
> that function...
>
> Has this bug been fixed in 7.4.0?
>
> If I were to fix this code, can I just use regular malloc()/free()
> or do I have to deal with memory pools? Should I just give a size to
> that field like char[32]? I'm really hesitant on doing the latter since
> I don't know how many of these objects are created.
>
> Then I would have to track down where bacula mallocs and frees
> FF_PKT stuff like term_find_files() and such.
>
> This is sort of a critical bug for me and motivated to have it fixed.
> I'm willing to do the work and submit a patch.
>
> 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
>

------------------------------------------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>