Archive for the Bug Category

__asm int 3 in template function ( in VC6 )

Posted in Bug on April 15, 2008 by naveenraj

We usually use __asm int 3 in the code to hard code break points. But have you tried setting a __asm int 3 in a template function? Like…

template<class T> int Testfunc( T Obj )
{
__asm int 3;
return Obj++;
}

void main()
{
Testfunc( 1 );
};

The above code will never get compiled in vc6. It will generate the below error

“fatal error C1001: INTERNAL COMPILER ERROR
(compiler file ‘msc1.cpp’, line 1794)
Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
Generating Code…Command line warning D4028 : minimal rebuild failure, reverting to normal build
Error executing cl.exe.”

But the same code will compile fine in later versions of visual studio. Seems they have fixed the bug 🙂

Advertisements

WM_DEVICECHANGE problem

Posted in Bug on January 3, 2008 by naveenraj
In one our Projects at company, we used WM_DEVICECHANGE message to detect the arrival and removal of USB devices. The application was supposed to run on a machine in which will be running along with several other utility applications. Some months after the project delivery, client reported that, sometimes even if a USB device is plugged in, it is not detected. Problem problem…..

After some investigations we found that if we make the window a top-level window (HWND_TOPMOST), there is no such problem s. But what’s the relation between the z-order and the above problem. Later we got few more points to identify the relation.

1. The WM_DEVICECHANGE is send to all the top-level windows according to their z-order. That is the window at the top most position receives the message first, the only the window below it and so one.

2. If a window got a WM_DEVICECHANGE and if it didn’t process the message with in a period (in my machine I think it was 20 secs), the message will not reach to the subsequent windows under it.

Now everything became clear to us, some window whose z-order is greater than our application window might have hung or didn’t process the message within 20 seconds. Thus our window didn’t get a chance. Also when we made our window top level it will be one of the first window’s to get WM_DEVICECHANGE message so reducing the number of windows above it to get hung. How ever we didn’t find a proper solution for this and moved to an alternative method to detect device arrival and removal.

I think windows might not be using the BroadcastSystemMessage() function with the BSF_FORCEIFHUNG flag, while sending the WM_DEVICECHANGE message.

Bug in Rich Edit control

Posted in Bug on October 31, 2007 by naveenraj

Basically this not a vc++ bug. Its actually a bug in the RichEdit control so the bug belongs to windows.

Check the picture…

What you see inside the red circle is the caret of rich edit control. It passed the boundaries of rich edit control and moved to the dialog.

Step to reproduce.

1. Create a dialog based application and place a rich edit control on it.
2. Give the Multi line and Auto HSCROLL style.
3. Now run the application and click inside the rich edit, and keep on pressing space bar. You can see the caret crossing the boundary of rich edit and starts moving through the dialog.

This problem exists in vista and XP. But I didn’t find a place to report this bug to Microsoft. I searched the whole internet to find some one already reported this problem. But coudn’t find any. I dont know why such a problem haven’t been noticed for the past 12 years( 12 years because I think the problem exists in the rich edit of 95 also ).