A Serious bug in VC.Net 2003 ?

  • Thread starter Thread starter Vinayak Raghuvamshi
  • Start date Start date
V

Vinayak Raghuvamshi

I have a simple, non-managed structure. When I create an array of this
struct, only the first item in the array gets created, the others are
not. Here is my sample code.

This works when I build using a plain Windows application. But it does
not work when i build using a .Net console application. Does anybody
have an idea what could be the issue here? Any help would greatly be
appreciated. This looks like a bug in the way VC.Net handles mixed
mode object creation.

#pragma once
namespace ADCache
{
//! stations seldom have more than two streams per box (one for
narrow band and one for broadband)
//! but lets be paranoid and be ready to handle upto 12 streams per
station
const int MAX_STREAMS = 12;
//! Settings related to a given station.
struct LCStationSettings
{
//! Settings related to a single stream. A physical machine can have
more than one media streams on it
struct LCStream
{
TCHAR name [MAX_PATH]; //!< a descriptive name for the stream
TCHAR id [MAX_PATH]; //!< the stream id. this value is provisioned
by the admgmt system for each station

LCStream(const LCStream& other)
{
*this = other;
}

LCStream& operator = (const LCStream& other)
{
_tcscpy(name,other.name);
_tcscpy(id,other.id);
return *this;
}

LCStream()
{
MessageBox(NULL,0,0,MB_OK);
_tcscpy(name,"NOTSET");
_tcscpy(id,"NOTSET");
}
};

LCStream lcstreams[MAX_STREAMS]; //!< an array of stream infos

};
}
// I try to create the object in the form_load
System::Void Form1::Form1_Load(System::Object * sender,
System::EventArgs * e)
{
LCStationSettings stationSettings;
}

When I check the memory of the stationSettings object right after the
creation, I can see just the first LCStream being created.

What is even more wierd is that the ctor of the LCStream does get
invoked 12 times, but somehow, only the first one seems to really
succeed.

Regards,
-Vinayak
 
Hi,

If it worked in plain windows application, it will also work in normal
win32 console application, regrading .Net Console or Winform now you use
mixed mode (managed + native), when you do that sometime the debugger
doesn't work correctly, it happen to me before that I can not see any native
variable or memory on the debugger, so to make sure that it is the debugger
or your code doesn't work correctly with mixed mode try to print the output
in a text file using nomral fwrite or fstream, and see if the output is what
you expect or not.

Regards,
Emad
 
Emad Barsoum said:
Hi,

If it worked in plain windows application, it will also work in normal
win32 console application, regrading .Net Console or Winform now you use
mixed mode (managed + native), when you do that sometime the debugger
doesn't work correctly, it happen to me before that I can not see any native
variable or memory on the debugger, so to make sure that it is the debugger
or your code doesn't work correctly with mixed mode try to print the output
in a text file using nomral fwrite or fstream, and see if the output is what
you expect or not.

Regards,
Emad
Click to expand...

Thanks for the tip. Incidentally, I did just what you suggested right
after I posted my message to this group, and you are right, it is just
the darned debugger.

What is scary is that even when you view the content of the memory
location using the memory window, you see incorrect results. So for
now, I am just outputting the suspicious variables to a file and
ensuring that I am getting what I am expecting....

I am surprised that there is no mention of a generic Debugger bug in
MS Kb.

Usually, when the debugger screws up, I just use the dbgclr and it has
always been reliable. But in this particular case, even dbgclr was
behaving incorrectly. So I wonder if there is a bug in visual studio
..Net that needs addressing....

thanks again.

-Vinayak
 
Back
Top