> > Thanks to pin this problem, I think that allocating 1 extra byte as we did in the > previous version will handle this problem. > > Unfortunately, the previous code was : > /* TODO: see if len contains already the 3 \0 */ > item = (CurFile *)jcr->file_list->hash_malloc(sizeof(CurFile)+len+3); > > And the new code is > item = (CurFile *)jcr->file_list->hash_malloc(sizeof(CurFile)+len); > > This is a serious issue that was easy to avoid... :( >
As long as it doesn't crash, any fix is good. My way saves an extra byte though - around 100kb of memory in my test case (basic domain controller with WSUS installed ;) I was trying to figure out how often this problem would occur... the average buffer size in my backup was around 210 bytes, and 3 big buffers were allocated, so I guess I should see this in around one in every 70 incremental accurate backups. I'm backing up 20 clients, with accurate backups done 3 times a day, 7 days a week, so if all the clients were upgraded to 5.2.2 I'd be seeing this crash somewhere in the order of 6 times a week! I guess it's a good thing I found it 2 days into testing with my first 5.2.2 test machine... :) James ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
