> > Hello, > > On 12/05/2011 10:08 AM, James Harper wrote: > >> 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... :( > >> > > > > Why 3? Could all 3 of the strings in there be blank? > > I wrote this code long time ago, and this is probably why I added this 3 bytes. > I have to admit that we should not have this condition, so this extra care is > probably not useful. > > I you can run some tests with only +1, it will be helpful. This error is not very > easy to reproduce. >
I tested with my fix which got the next incremental through, and now I doubt it will fail anymore because the accurate list will be different if I run it again. I think you can prove it correct by analysing the inputs though. Another way would be to make the htable stuff write a pattern after each allocation (add some headroom on the size of the "big buffer" to the last allocation works) and check on the next allocation that the pattern is still the same. It just seems clumsy to add an extra 3 bytes when all you need is one just in case an unknown activity might overwrite them. 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
