Comments on Entropy Overload: Memory leaks, log analysis and Unix command-line t...

package.c as called by browcmgr.c

2010-09-20T17:17:16.070+01:00

package.c as called by browcmgr.c

Wow, that's interesting, Barry... So, what wa...

2010-09-20T16:48:13.886+01:00

Wow, that's interesting, Barry...

So, what was the bug eventually?
Where was it found?

debug.c? unit.c? writeobj.c?

-- A friend.

Interesting article, Barry. Somehow this resembles...

2010-09-13T21:45:31.382+01:00

Interesting article, Barry. Somehow this resembles the way I tackle the most complicated issues as well.

I am an extensive user of instrumentation based logs. These come very handy in situations that the bugs reveal themselves at customer sites only. And it has often helped me to solve the issues simply by looking at the logs without even tryin to reproduce myself. However, the log can easily become too big for most editors - and it takes some expertise to find the correct information from a 2GB log file :)

I often use the same Unix tools as you do (awk can also come handy for operations that require inspection of several lines) in Linux, where it is much easier to work with large files as well. I found cygwin too awkward already ~10 years ago, compared to a real unix...

Thanks for sharing. My experience with Unix comman...

2010-08-30T13:34:11.160+01:00

Thanks for sharing. My experience with Unix command line utilities doesn't go beyond sed and grep, so it was very useful to get a practical example.

Oh, and it might be the fact that most non-trivial bugs are really fixed by "psychic debugging" (a term which I believe was coined by Raymond Chen: http://blogs.msdn.com/b/oldnewthing/archive/2005/03/21/399688.aspx) instead of tool-based debugging that keeps more experienced people from discussing their approaches. Even though some people discuss how they do "psychic debugging" (Raymond being one of them), it mostly happens when someone had occasion to use/show off his "super powers" in the process of psychic debugging.

My approach to resolve most of my bugs is loosely based on "psychic debugging", but not spectacular at all. Of course I use a normal debugger to get rid of the "easy" bugs, but when I'm not able to find the cause of a difficult problem, I start reading the code (or recalling it, which is even easier if I wrote the code myself :) ), trying to grasp the intentions. Usually at some point there is this "light bulb" moment, and I see how the bug can happen in the given circumstances. But I really have no idea how I could discuss this approach in a way that is useful for others :)

Well, AQtime certainly located the bug in the comp...

2010-08-30T13:16:20.108+01:00

Well, AQtime certainly located the bug in the compiler, and gave a hint as to where to look, so it wasn't useless by any means.

I should expect that the bug is indeed fixed in XE.

Hmmm, in this case AQTime didn't seem to be qu...

2010-08-30T13:05:33.100+01:00

Hmmm, in this case AQTime didn't seem to be quite useful ...

Just curious: Should we expect the mentioned leak is fixed in XE ?