I have a silly demo program that I have been using for a few years to demonstrate the Simics Analyzer ability to track software programs as they are executing and plot which threads run where and when. This demo involves using that plot window to virtually draw text, in a way akin to how I used to make my old ZX Spectrum “draw” things in the border. But when I brought it up in a new setting it failed to run properly and actually starting hanging on me. Strange, but also quite funny when I realized that I had originally foreseen this very problem and consciously decided not to put in a fix for it… which now came back to bite me in a pretty spectacular way. But at least I did get an interesting bug to write about.
Every once in a while I need to build demo setups to show debugging in action. As I have blogged before, finding a good bug when you need one isn’t always easy. The solution is to try to invent artificial bugs, and I was very happy when I managed to stage a buffer overrun in a VxWorks program.
It is pretty very nice demo in which you first start a period program A, which prints the value of an incrementing counter every target second. You then run a supposedly unrelated program B, resulting in the values that program A prints to become corrupted. Perfect to show off reverse execution and data breakpoints in reverse as you go from the point where the corrupted value is printed to the piece of code that overwrote the variable.
But then I ported the demo to a new platform… and the bug didn’t work anymore. My bug had caught a bug and was now not working, or at least not they way I expected it to. What had happened?
Continue reading “My Bug Doesn’t Work!”
I am using TortoiseGit on Windows for a while now, and it works OK. However, today, it just stopped working. The error I got persistently was:
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68540000, RegionSize 0x480000, State 0x10000 c:\msysgit\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
It is a symptom of bad UI design when things just happen, and you have no why, and no visible indication to help you figure it out. Last night, I noted that the text in Outlook when composing email suddenly was way larger than normal. I put that way as a fluke, but today, the effect was still there, all the time. Strange. So I went in and checked my font settings, which were all fine. This being Office 2007, I suspected some kind of zoom effect, but there was no zoom indicator in any Outlook window. I tried ctrl-+ and ctrl– to see if Outlook respected the web-style view size shortcuts. But no effect.