December, 2004


17
Dec 04

Find in Files and Project Properties

Two of the big new features to debut in the next release of Programmers Notepad will be Find in Files and Project Properties. Find in Files is essentially complete and work has begun on project properties.

Testers on the pn-discuss mailing list are playing with these features now to find and squash bugs.

Here are some screen captures:

Project Properties dialog, only one property set showing: (picture)

New find dialog showing Find in Files, and Find in Files results window:


17
Dec 04

USES_CONVERSION – a cautionary tale

Yesterday my team at work finally got to the bottom of a crash in a product that was very difficult to track down. We had a thread running in a product that was now being required to run for much longer, and was eventually producing a stack overflow exception (which we’d not seen before). As is the nature of such an exception, it often came from different points in the thread depending on the work that was being done.

To cut a long and painful bug-tracking story short, it turns out that the memory allocation performed by the macros related to ATL’s USES_CONVERSION text-encoding conversion system is performed by the alloca function. This function allocates memory on the stack (an AHA! moment) and what’s more this memory does not obey the standard stack-scoping rules:

void fn()
{
    while(true)
    {
        {
            USES_CONVERSION;
            DoSomething(A2W("SomeString"));
        }
    }
}

Some might expect the above code to release the memory allocated by A2W each time around the loop – wrong! The memory allocated by alloca does not get released until the current function is left, so to fix this problem you have to write code like this:

void fn2()
{
    USES_CONVERSION;
    DoSomething(A2W("SomeString"));
}

void fn()
{
    while(true)
    {
        fn2();
    }
}

This code was part of a Visual C++ 6 project, and apparently in VC7 there are alternative better macros that use proper stack scoping for allocation – good! We found the first signs of the true location of the bug by converting the project to VC7 and running it there – where the stack trace exception always seemed to occur on the line where the A2W macro was being used. I think this was probably just good fortune rather than VC7 being exceptionally helpful (no pun intended!).

So: Don’t use USES_CONVERSION and friends in thread functions or tight loops – you have been warned!