Debug Faster. Debug Smarter.

My CodeRage XI session on debugging in RAD Studio is now available on YouTube.

If you have missed the presentation or want to see it again, now is a good time :)

Additional materials (slides, code) are available on the Presentations page.

Hear me speak at CodeRage XI

This year I’ll be presenting two sessions at CodeRage XI.

On Wednesday, I’ll be exploring the topic of debugging in RAD Studio. I’ll show how advanced options in breakpoint properties work and drop some debugging tips & tricks here and there. Join me in room 1 at 7 am PST / 10 am EST / 16.00 CET.

On Thursday I’ll be demoing new enhancements in FastMM. If you are writing multithreaded code, then this session will be targeted to you! Join me in room 1 at 10 am PST / 1 pm EST / 19.00 CET.

Defensive Programming and Advanced Debugging

Next Wednesday (9th) I’ll be holding a presentation in Ljubljana. Topic: defensive programming, maintaining a clean code, and debugging tips and tricks. Presentation will be applicable to both Delphi and C++Builder programmers.

As usual, I’ll be presenting in Slovenian language.

For more information and registration click here!

XE5 and USB Drivers

If your XE5 installation doesn’t want to recognize attached Android phone when Windows see it perfectly well (and you have done all the groundwork including putting the phone into USB Debugging mode), check if you have installed USB drivers that support adb – the android debugger. Typically, the drivers that are installed automatically by Windows won’t work with the adb.

This page links to correct drivers for various phone manufacturers.

This StackOverflow topic may help you in case of hard-to-resolve problems.

And, of course, read the official documentation on debugging on Android devices first!

Hacking FastMM for Debugging Purposes

Last week I started solving weird ‘out of memory’ crash in one of our services. First reports of problems came in from a client but with some experimenting I managed to repeat it on the test configuration. The program works nicely for few hours and then something weird happens and it starts using the memory, few megs per minute, until it crashes.

Repeating the problem on the test configuration usually means half the victory won but this time it wasn’t so :( I was fighting the most terrible of memory leaks – a live leak. Memory was allocated, stored away in some management structure and properly disposed off when the program terminated. FastMM have shown no problems at all. Such problems are always hard to find.

Introduction to Debugging

Blaise Pascal Magazine #21 is out with with my introductory article on debugging. Two more advanced articles on the same topic are scheduled to follow.

Blaise Pascal Magazine Rerun #8: Debugging Multithreaded Applications

This article was originally written for the Blaise Pascal Magazine and was published in Issue #14.

How to Find a Missing _Release

For quite some time, thread pool in OmniThreadLibrary had a weird problem – if you scheduled more than 80 tasks in one go, FastMM would report memory leaks when application was terminated. It bothered me, of course, but I could never find the real reason behind the problem. And so I left the code “as is” and said to myself that nobody would encounter it in practice, anyway.

And then Žarko came and wrote about me on his blog :( In case you are living in a dark cave and didn’t hear of him – Žarko runs immensely popular Delphi site at About.com. His testing (and most of all his highly reproducible test case) gave me a new energy to pursue the problem.

The reason for the memory leak was a reference count leak in TOmniInterfaceDictionary, which is now fixed in the SVN. I also found some very tricky race conditions in TOmniTask.Execute and TOmniTask.Terminate and a cause for weird "A call to an OS function failed" error in DispatchEvent. All in all, I had two very productive bug-hunting nights. But that’s not why I started writing this article. I wanted to tell you a debugging story titled “How to find a missing Release.”