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