Board index » cppbuilder » Re: Yet another show stopping bug!!!

Wiljo

CBuilder Developer
 

Re: Yet another show stopping bug!!!


2005-10-05 03:54:35 PM
cppbuilder12
Zach Saw wrote:
Quote
Well, it's not a show stopper for the compiler, that's for sure. I was just
feeling a bit fed up with Borland after one week of debugging and root
causing the problem. :)

Anyway, I've already mentioned the correct workaround in my report in QC
(Please refer to qc.borland.com/wc/qcmain.aspx

Here is that workaround.
Quote
declare Index first:
int Index;
while (Index = ...)

However, this will cause the compiler to complain about a possible incorrect
assignment.

But now the compiler generates a warning, and that is no good in my book. I must
say that I am surprised that only declaring the int outside the while statement
prevents that memory leak. I consider it best practice to declare any variables
just after the closest opening brace '{' of a compound statement, but never
inside an iterative loop.
I have also found that using AnsiString as arguments for functions causes some
memory leaks, and therefore we have written our own string class that doesn't
have a memory leak.
But to return to the workaround at hand. Although this works at run time, there
still is a compile time warning. A good workaround for this is in the comma
operator:
while( Index = ..., Index != 0 )
or applying parenthesis, whichever one finds handy (or legible):
while(( Index = ... ) != 0 )
What about this? The compiler will stop complaining, and code works as expected
without any problem.
Best Regards,
Wiljo.
 
 
AlexB

CBuilder Developer

2005-10-05 08:22:25 PM

Re:Re: Yet another show stopping bug!!!

Zach Saw wrote:
Quote
hmm... starting to think no one actually reads my QC report :)
My comment for your previous report:
------------------------------------
Quote
Do not pass let the compiler perform type cast on a parameter
to a constructor if the parameter is a class declared with
RTL_DELPHIRETURN. RTL_DELPHIRETURN classes
are such as AnsiString, WideString, Currency etc.
The bug still exists if any temporary object with destructor goes as
parameter for constructor. Example (tested with BCB5 Up1):
class TDummy
{
public:
__fastcall TDummy(const char* p) {};
__fastcall ~TDummy(void) {};
}
class LeakMe
{
char leaked[10240000];
public:
__fastcall LeakMe(const TDummy& d) { throw 0; };
};
void __fastcall TForm1::Button1Click(TObject *Sender)
{
try
{
LeakMe*p=new LeakMe(TDummy("test"));
delete p;
}
catch (...) {}
}
Leak occures if TDummy has destructor. If this destructor is commented
out no leak occures.
So workaround is more strict:
Do not call constructor with temporary objects as parameter if temporary
object has destructor.
Or avoid any temporary objects at all...
-----------
Alex.
 
Zach Saw

CBuilder Developer

2005-10-05 11:41:05 PM

Re:Re: Yet another show stopping bug!!!

Oh god. This is more serious than I thought. It's not just the
RTL_DELPHIRETURN classes that causes the compiler to fail -- even a simple
class will cause a mem leak.
Anyway, tested it with BCB6 Up4 and it's still the same.
Thanks Alex.
"AlexB" < XXXX@XXXXX.COM >wrote in message
Quote
Zach Saw wrote:
>hmm... starting to think no one actually reads my QC report :)
My comment for your previous report:
------------------------------------
>Do not pass let the compiler perform type cast on a parameter
 >to a constructor if the parameter is a class declared with
 >RTL_DELPHIRETURN. RTL_DELPHIRETURN classes
 >are such as AnsiString, WideString, Currency etc.
The bug still exists if any temporary object with destructor goes as
parameter for constructor. Example (tested with BCB5 Up1):

class TDummy
{
public:
__fastcall TDummy(const char* p) {};
__fastcall ~TDummy(void) {};
}

class LeakMe
{
char leaked[10240000];
public:
__fastcall LeakMe(const TDummy& d) { throw 0; };
};

void __fastcall TForm1::Button1Click(TObject *Sender)
{
try
{
LeakMe*p=new LeakMe(TDummy("test"));
delete p;
}
catch (...) {}
}

Leak occures if TDummy has destructor. If this destructor is commented out
no leak occures.

So workaround is more strict:
Do not call constructor with temporary objects as parameter if temporary
object has destructor.
Or avoid any temporary objects at all...
-----------
Alex.
 

{smallsort}
Zach Saw

CBuilder Developer

2005-10-05 11:45:25 PM

Re:Re: Yet another show stopping bug!!!

I've tried the dtor thing with this bug though -- seems to only affect
RTL_DELPHIRETURN classes. This leads me to think those 2 bugs are totally
unrelated.
"AlexB" < XXXX@XXXXX.COM >wrote in message
Quote
Zach Saw wrote:
>hmm... starting to think no one actually reads my QC report :)
My comment for your previous report:
------------------------------------
>Do not pass let the compiler perform type cast on a parameter
 >to a constructor if the parameter is a class declared with
 >RTL_DELPHIRETURN. RTL_DELPHIRETURN classes
 >are such as AnsiString, WideString, Currency etc.
The bug still exists if any temporary object with destructor goes as
parameter for constructor. Example (tested with BCB5 Up1):

class TDummy
{
public:
__fastcall TDummy(const char* p) {};
__fastcall ~TDummy(void) {};
}

class LeakMe
{
char leaked[10240000];
public:
__fastcall LeakMe(const TDummy& d) { throw 0; };
};

void __fastcall TForm1::Button1Click(TObject *Sender)
{
try
{
LeakMe*p=new LeakMe(TDummy("test"));
delete p;
}
catch (...) {}
}

Leak occures if TDummy has destructor. If this destructor is commented out
no leak occures.

So workaround is more strict:
Do not call constructor with temporary objects as parameter if temporary
object has destructor.
Or avoid any temporary objects at all...
-----------
Alex.
 
Zach Saw

CBuilder Developer

2005-10-05 11:50:24 PM

Re:Re: Yet another show stopping bug!!!

Quote
I'm wondering now if the infamous 'fragmented heap' issue that has
plagued us occasionally over the years (currently not a problem AFAIK)
might not be the result of such bugs. At least our apps only need be
able to run for a few hours most of the time and a few days
occasionally. I really wouldn't like to have to write something with
24/7 uptime requirements using BCB.
What should we use if one of the criteria is that the language must be C++?
Is MSVC better than C++ in terms of stability? I don't mind developing the
front ends using BCB, but for the rest of it, I'm looking for something more
solid. I guess I shouldn't have developed the server using BCB.
 
Andrue Cope [TeamB]

CBuilder Developer

2005-10-06 12:00:46 AM

Re:Re: Yet another show stopping bug!!!

Zach Saw wrote:
Quote
What should we use if one of the criteria is that the language must
be C++? Is MSVC better than C++ in terms of stability? I don't mind
developing the front ends using BCB, but for the rest of it, I'm
looking for something more solid. I guess I shouldn't have developed
the server using BCB.
I'm not sure. If we had to switch we'd probably switch to VS.NET simply
because that's what the other half of our development team uses.
Historically VC hasn't been very standards compliant but the last
release seems to have addressed that.
As regards the quality of generated code I would guess that VS.NET is
very good solely because so many developers use it.
I wonder what other people will suggest though.
What with .NET sort of maybe catching on, a company takeover, DeXter,
our main project reaching a watershed, Windows Vista and Win64 it's
becoming an interesting topic for discussion here. You can never find a
crystal ball when you want one :-/
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html