4 ms·

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what.

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what. That's a fact in software development.

stinos 12y ago
Sure, but the thing is: one developper (or a group of) said 'well let's enable this' and then nobody else reviewed that or thought 'hmm, surely it can't be good to just start logging pretty much everything'? Just wondering how that happens in large companies.
- heinrich5991 12y ago
  From the article: >In OS X 10.10, this logging was turned on by default for some applications that use a custom memory allocator, such as jemalloc, because of an initialization bug in the framework. So it seems to be a bug that it even got enabled.
- kbar13 12y ago
  mistakes happen
- rmorell 12y ago
  Nobody explicitly decided to enable the logging by default. It was caused by an uninitialized variable. Uninitialized variables result in undefined behavior, but can often go unnoticed in practice if the code around them results in the value in memory (or register) for that variable usually being a certain value. In this case, it happened to result in logging being disabled by default in most situations. But using jemalloc for the process rather than the standard malloc implementation was enough to cause the opposite result, apparently due to jemalloc poisoning malloc()ed regions (which overwrote the "usual" value).
  - saidajigumi 12y ago
    > It was caused by an uninitialized variable. And in case anyone thinks that sheer developer machismo (or 'rigor' or whatever) can keep you out of harm's way here, then I suggest reading John Carmack's excellent writeups on the horrors found by static code analysis.[1][2] Even the best programmers out there will get caught by any number of language traps. [1] Sadly/happily, still available via archive.org. CSS seems to be busted here, so scroll to the bottom for Carmack's article: https://web.archive.org/web/20120104024203/http://altdevblogaday.com/2011/12/24/static-code-analysis/ [2] The above was discussed on HN, and that thread is pretty good as well: https://news.ycombinator.com/item?id=3388290 https://news.ycombinator.com/item?id=3388290

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what. That's a fact in software development.

stinos 12y ago

Sure, but the thing is: one developper (or a group of) said 'well let's enable this' and then nobody else reviewed that or thought 'hmm, surely it can't be good to just start logging pretty much everything'? Just wondering how that happens in large companies.

heinrich5991 12y ago
From the article: >In OS X 10.10, this logging was turned on by default for some applications that use a custom memory allocator, such as jemalloc, because of an initialization bug in the framework. So it seems to be a bug that it even got enabled.
kbar13 12y ago
mistakes happen
rmorell 12y ago
Nobody explicitly decided to enable the logging by default. It was caused by an uninitialized variable. Uninitialized variables result in undefined behavior, but can often go unnoticed in practice if the code around them results in the value in memory (or register) for that variable usually being a certain value. In this case, it happened to result in logging being disabled by default in most situations. But using jemalloc for the process rather than the standard malloc implementation was enough to cause the opposite result, apparently due to jemalloc poisoning malloc()ed regions (which overwrote the "usual" value).
- saidajigumi 12y ago
  > It was caused by an uninitialized variable. And in case anyone thinks that sheer developer machismo (or 'rigor' or whatever) can keep you out of harm's way here, then I suggest reading John Carmack's excellent writeups on the horrors found by static code analysis.[1][2] Even the best programmers out there will get caught by any number of language traps. [1] Sadly/happily, still available via archive.org. CSS seems to be busted here, so scroll to the bottom for Carmack's article: https://web.archive.org/web/20120104024203/http://altdevblogaday.com/2011/12/24/static-code-analysis/ [2] The above was discussed on HN, and that thread is pretty good as well: https://news.ycombinator.com/item?id=3388290 https://news.ycombinator.com/item?id=3388290