About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense to fix them even if there are no crashes (yet?). The patch is attached (of course it can't fix the removed assert because it doesn't fix any leak). -------------- next part -------------- A non-text attachment was scrubbed... Name: num_comments.patch Type: application/octet-stream Size: 2693 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20150704/c8165f11/attachment-0001.obj
lvqcl wrote:> It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. > Otherwise there's probably a leak somewhere that should be fixed.Now I'm not sure about this, maybe it's wrong, and in this case comments is just an array with 0 (==num_comments) valid elements.
What is the advantage of removing an assert? - even FLAC_ASSERT() My understanding is that assert() is only compiled into the code with Debug builds, whereas with a Release build the assert() macro will generate no code at all. In other words, when you build for testing, the assert is there, but when you build the fully optimized version the assert will be removed anyway. Seems safer to leave the FLAC_ASSERT() and then work to make sure the tests cover the potential memory leaks as well as ensure that fully-optimized release builds turn off all assert() macros. Brian Willoughby Sound Consulting p.s. I haven't looked too closely at this specific commit change, but speak from general experience. On Jul 4, 2015, at 4:30 AM, lvqcl <lvqcl.mail at gmail.com> wrote:> About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 > > It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. > Otherwise there's probably a leak somewhere that should be fixed. > > > > I found several places where the situation is reverse: > comments can be 0 but num_comments is not; IMHO it makes sense > to fix them even if there are no crashes (yet?). > > The patch is attached (of course it can't fix the removed assert because it > doesn't fix any leak).<num_comments.patch>
Brian Willoughby wrote:> What is the advantage of removing an assert? - even FLAC_ASSERT()This specific commit was removed because it firing too often when I was running flac compiled with --enable-debug under the American Fuzzy Lop file fuzzer.> My understanding is that assert() is only compiled into the code with > Debug builds,This is correct, but what sort of things are being checked with asserts that you do not want to check in the Release builds? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
lvqcl wrote:> I found several places where the situation is reverse: > comments can be 0 but num_comments is not; IMHO it makes sense > to fix them even if there are no crashes (yet?).Applied and fixed this as well: + block->num_comments == 0; Ooops ;-). Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/