On 12/05/2011 10:03 AM, James Harper wrote: >> >> 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 ;)
In fact, the next buffer start will be aligned for a pointer, so 1 bytes won't probably make any difference. Bye > 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... :) -- Need professional help and support for Bacula ? Visit http://www.baculasystems.com ------------------------------------------------------------------------------ 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
