Board index » cppbuilder » Re: AV on delete operator

Re: AV on delete operator


2005-02-17 08:19:29 AM
cppbuilder90
"Wiljo" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...
Quote
Hi,

Andrue Cope [TeamB] wrote:

Anything that is allocated through new or new[] will be freed by a delete or
delete[] eventually, either literally or through a destructor. But momentarily I
can't guarantee that both happen in the same package. Thus how do I make sure
that every package uses the same memory (heap) manager?

I already talked about using a linked list. Every base node, because nodes can
be derived for different purposes, has an overloaded operator new and an
operator delete defined as member, see sample code:
You may try to comment out some suspect delete or delete[] calls and see
if CG reports leaks. If not, something else may be deleting this object.
After delete you may also try setting it to 0 as subsequent deletes
will most likely cause an AV where deleting 0 is a noop.
Quote
Somewhere else in the newsgroup was a mention that using Dynamic RTL should be
avoided, and I have also disabled it, but is this thread the option was
encouraged. I am confused as to the best approach. What can I expect to see
happen when I enable it again for all my packages?
Codeguard can be problematic without Dynamic RTL and debug libs. I would
normally have these two set in debug builds but not in release builds.
 
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
>Oh dear. Rebooting your machine would probably have been enough.
What do you think I did first?
Lol, I wasn't sure - no offense intended.
Quote
Well it didn't startup again in my case.
Spooky :(
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
Thus how do I make sure that every package uses the same memory
(heap) manager?
The following comment should appear in the main file of our DLL/package
projects:
//----------------------------------------------------------------------
-----
// Important note about DLL memory management when your DLL uses the
// static version of the RunTime Library:
//
// If your DLL exports any functions that pass String objects (or
structs/
// classes containing nested Strings) as parameter or function
results,
// you will need to add the library MEMMGR.LIB to both the DLL
project and
// any other projects that use the DLL. You will also need to use
MEMMGR.LIB
// if any other projects which use the DLL will be perfomring new or
delete
// operations on any non-TObject-derived classes which are exported
from the
// DLL. Adding MEMMGR.LIB to your project will change the DLL and its
calling
// EXE's to use the BORLNDMM.DLL as their memory manager. In these
cases,
// the file BORLNDMM.DLL should be deployed along with your DLL.
//
// To avoid using BORLNDMM.DLL, pass string information using "char
*" or
// ShortString parameters.
//
// If your DLL uses the dynamic version of the RTL, you do not need to
// explicitly add MEMMGR.LIB as this will be done implicitly for you
//----------------------------------------------------------------------
-----
But if you don't want to do this the only way to ensure you don't have
"cross-contamination" is to ensure that for every exported function
that allocates something there is an exported function to deallocate
it. You will probably also need functions to copy things like linked
lists to transfer ownership.
But if all your packages have been compiled with CG enabled it should
be spotting this problem.
BTW:Sorry if I've occasionally been stating the obvious - no insult is
intended.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

{smallsort}

Re:Re: AV on delete operator

Andrue Cope [TeamB] wrote:
Quote
Wiljo wrote:


>>Oh dear. Rebooting your machine would probably have been enough.
>
>What do you think I did first?


Lol, I wasn't sure - no offense intended.


>Well it didn't startup again in my case.


Spooky :(
Hello again,
Ok, it just happened again! After enabling CG in all projects and recompiling
everything, the Builder vanishes somewhere during the build. And the Builder
just won't return anymore. I have even rebooted the computer, but to no avail.
Only the Builder splash screen is shown, and then it dies. It looks like I have
to reinstall Builder C++ 6 all over again. I am even starting to wonder why I
bother doing this. There is only one good reason, because we can't just switch
to another platform. We are already to involved with the Builder C++ to make the
switch. We are already two months behind with a release, and switching to
another platform now only increases this delay by at least another six months.
In our case Builder C++ is very unstable, it crashes several times a day. And we
did already learn to live with that, but having to reinstall Builder once a week
is really too much.
How do we find the bug in our program, if there really is one, if the Builder
keeps making my life a misery.
When all sources are in one project called ALL.EXE, that program is very stable.
We very much like to split up our program into different borland packages
(*.bpl), to keep an overview of everything. One project with over a hundred
sources is just too big to handle.
Sorry if I seem to be agitated, but I do no longer know what to do now. Writing
a program, that looks to be unstable although we don't know why, is bad enough.
But working with an unstable Builder to solve this is a lot worse.
Wiljo.
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
Ok, it just happened again! After enabling CG in all projects and
recompiling everything, the Builder vanishes somewhere during the
build.
Can we just confirm the version and patch level of your copy of
Builder? There was once an issue relating to CG and __int64 but I
can't remember which version it plagued. I think that just produced an
internal compiler failure but something like that could perhaps cause
Builder to crash.
Quote
How do we find the bug in our program, if there really is one, if the
Builder keeps making my life a misery.
I don't think it's Builder's fault per se. I'm not trying to pass the
buck or anything but my experience both of using Builder and of
participating in these groups for several years is that with the
possible exception of BCB3 the IDE has never been what you might call
'unstable'.
Builder might be crashing because you are installing packages that are
unstable into the IDE. The IDE is only as stable as the least stable
package that has been installed. I confess to regarding packages as
something of a black art and have never liked them. This is one reason.
How do you debug something when the IDE is being destabilised by the
code you are trying to debug?
Quote
When all sources are in one project called ALL.EXE, that program is
very stable. We very much like to split up our program into different
borland packages (*.bpl), to keep an overview of everything. One
project with over a hundred sources is just too big to handle.
From whose POV? If the developer's then fair enough but the IDE should
be fine with that size project.
Our two biggest are a DLL which doesn't use any visual VCL stuff:232
units and an application that does use visual VCL stuff:198 units. They
both build in under two minutes and cause us no more problems than the
smaller projects. I'm not saying that such a large project is ideal
from a developer POV but Builder seems quite happy.
How about splitting your project into separate DLLs rather than BPLs.
The difference is only the integration into the IDE I think. DLLs don't
integrate at all whereas BPLs can.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
Andrue Cope [TeamB] wrote:

>Wiljo wrote:
>
>
>>>Oh dear. Rebooting your machine would probably have been enough.
>>
>>
>>What do you think I did first?
>
>
>
>Lol, I wasn't sure - no offense intended.
>
>
>>Well it didn't startup again in my case.
>
>
>
>Spooky :(

Hi,
After installing the Builder, and rebooting the system, I usually install the
4th patch of the Builder. Halfway during this install I get the following error:
Setup has detected a -115 error while attempting to copy files.
his can be caused by a file being used while trying to install.
Component: Program Files\Main Program Files
File: C:\Program Files\Borland\CBuilder6\Bin\bcbsmp60.bpl
Error: -115
[OK]
Thus in other words, even installing a patch doesn't work. I have experienced
this before, because we install the Builder at least once per six months, only
lately we need to install it more often. Last week I didn't bother with
installing the patch, just to see what would happen. My thoughts were, that I
could always install the patch later in case of problems.
Wiljo.
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
After installing the Builder, and rebooting the system, I usually
install the 4th patch of the Builder. Halfway during this install I
get the following error:

Setup has detected a -115 error while attempting to copy files.
Try posting that as a separate question into the .install newgroup
section. It isn't normal and if the result is a corrupt or mismatched
bcbsmp60.bpl it would certainly destabilise Builder.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: AV on delete operator

Andrue Cope [TeamB] wrote:
Quote
Can we just confirm the version and patch level of your copy of
Builder? There was once an issue relating to CG and __int64 but I
can't remember which version it plagued. I think that just produced an
internal compiler failure but something like that could perhaps cause
Builder to crash.

We have Borland C++ Builder Professional
Version 6.0 (Build 10.166)
for Windows 2000 (Build 2195: Service Pack 4)
Installing Update Pack 4 for the Builder failed, as I mentioned in my previous
posting.
I did install Patch 1, when P#4 failed, but when I tried to instal Patch 2, I
got the same error as with Patch 4. I already guessed that Patch 4 includes all
previous patches, thus that was expected. I will try rebooting and installing
Patch 4 again, maybe it will work.
Quote

How about splitting your project into separate DLLs rather than BPLs.
The difference is only the integration into the IDE I think. DLLs don't
integrate at all whereas BPLs can.
We have looked into that, but when debugging the program, we can no longer trace
into the code of the DLL, and with a BPL we can. And since most of our code
resides inside a Package, debugging would no longer be possible. It looks like
we have to put all the sources in one EXE project to take the benefit of
debugging into account. Thus dropping either PKG, DLL or LIB altogether. And
from the developers POV, we can live with that.
Builder is up and running again, so I will be testing ALL.EXE for any failures.
I have disabled CG for the moment. And will debug any code that behaves erratically.
Thanks
Wiljo.
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
We have looked into that, but when debugging the program, we can no
longer trace into the code of the DLL, and with a BPL we can.
Are you using Windows XP? There is a gotcha relating to debugging DLLs
under that version of windows:
The following is actually the comment for Delphi but still applies:
"If you use Windows XP, you should have difficulties with debugging
DLL-libraries. They are as follows - the Delphi de{*word*81} does not load
the debugging information symbols from the library.
This mistake has already been corrected for Delphi 7, but if you work
with the earlier versions, you may find the following advice useful: do
all the preparations for debugging as described above, then start
debugging. Once the main application has been started, switch to Delphi
and press the Ctrl + Alt + M combination of keys. In the opened list of
the loaded modules find your module, right-click on it and choose
Reload Symbol Table. Enter the complete path to your DLL in the window,
which will appear, and press OK. The remote debugging symbols table
should be reloaded and you will get the opportunity to set up the
breakpoints and track your Shell extension work."
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: AV on delete operator

Andrue Cope [TeamB] wrote:
Quote
I don't think it's Builder's fault per se. I'm not trying to pass the
buck or anything but my experience both of using Builder and of
participating in these groups for several years is that with the
possible exception of BCB3 the IDE has never been what you might call
'unstable'.

We are programming in C++ now for about 15 years. First in Turbo C++, followed
by Borland C++, and now for three years in C++ Builder 6. Our experience is that
our version of C++ Builder is "unstable", but this could be due to packages or
something. It wasn't unstable in the beginning, but the past year it has become
more and more unstable. So I guess we must be doing something wrong. But looking
through the newsgroups, we are not the only one's with an 'unstable' Builder.
Quote
Builder might be crashing because you are installing packages that are
unstable into the IDE. The IDE is only as stable as the least stable
package that has been installed. I confess to regarding packages as
something of a black art and have never liked them. This is one reason.
How do you debug something when the IDE is being destabilised by the
code you are trying to debug?

There you have a point. We have only one external package installed for the
OpenGL, but this one works fine. Atop of that we have a package of our own that
installs some new components, like an extended TCheckTreeView component and a
TEditFloat with boundaries. Also this package works fine.
Quote

Our two biggest are a DLL which doesn't use any visual VCL stuff:232
units and an application that does use visual VCL stuff:198 units. They
both build in under two minutes and cause us no more problems than the
smaller projects. I'm not saying that such a large project is ideal
from a developer POV but Builder seems quite happy.

All our packages use VCL stuff, sometimes from inside a thread. But from within
a thread we use the Synchronize method to overcome any problems in that area.
The Borland C++ environment had something like SourcePools, we were very fond
of. I am sorry to see that C++ Builder lacks this feature. We are looking
forward to a new version of the Builder.
Wiljo.
 

Re:Re: AV on delete operator

Andrue Cope [TeamB] wrote:
Quote
Are you using Windows XP? There is a gotcha relating to debugging DLLs
under that version of windows:

No we are using:
Microsoft Windows 2000
5.00.2195
Service Pack 4
and our hardware:
ASUS Laptop, Intel Pentium 4, 2.00GHz, 512MB RAM
Wiljo.
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
Microsoft Windows 2000
5.00.2195
Service Pack 4

and our hardware:

ASUS Laptop, Intel Pentium 4, 2.00GHz, 512MB RAM
That's pretty much what I'm using although it's a desktop machine with
twice the RAM. I have no problems debugging DLLs. In fact I sometimes
wish Builder would act differently because we have a lot of callbacks
and it's sometimes easy to forget whether you're debugging EXE code or
the DLLs.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: AV on delete operator

Hi,
Momentarily we have put all source files in one EXE project, instead across
several Borland packages (*.bpl). This, and correcting some strange thread
behaviour, seems to make our program stable again. Extreme testing this morning
didn't make the program crash anymore. I will explain this strange thread
behaviour, that might be responsible for some Access Violations.
I have already mentioned that every extensive job our program does is handled by
a seperate thread. This thread shows it's progress on a seperate Form, using the
Synchronize method. Form and thread are created in the following code description:
Creation of FormRun
Creation of suspended ProgressThread
ProgressThread->OnTerminate = FormRun->onThreadTerminate
ProgressThread->FreeOnTerminate = false
FormRun->ShowModal() is called
FormRun::OnShow resumes the thread
The thread performs the extensive job that needs to be done, showing it's
progress on FormRun. When the thread finishes, the function
FormRun->onThreadTerminate is automatically called. This function in turn sets
the FormRun::ModalResult to either mrOk or mrCancel, indicating success or
failure from the ReturnValue of the ProgressThread.
FormRun->ShowModal() only exits when the ProgressThread is finished. An Ok
boolean is set to true when ModalResult == mrOk.
Deletion of ProgressThread
Deletion of FormRun
The Ok boolean is returned to whoever called this procedure.
An AV would usually occur on the deletion of FormRun, even when I comment that
line of code(?YES THIS REALLY TAKES PLACE?)! When the FormRun is not deleted, it
will be reused the next time the procedure is called.
It appears that the thread is still running somehow, because when I add a
ProgressThread->WaitFor() right before it's deletion, the Access Violation does
not arise. The WaitFor function takes approximately one second to complete.
During a test I call the procedure 25 times. Without the WaitFor call, the
Access Violation on the FormRun destructor is shown at the end of one iteration,
you can see that the next iteration does take place, because FormRun reappears
and the thread starts again. This is while the Access Violation Dialog is still
present on screen.
With the WaitFor call the problem seems to be solved!
Does anyone have any comment on this, why a WaitFor call is needed even when the
thread is supposed to be finished anyway?
Wiljo.
 

Re:Re: AV on delete operator

Hi,
Another thing that starts happening since yesterday, is a CodeGuard Warning at
the start of the program:
BORLNDMM.DLL has already allocated memory which may now be reported as false
leaks. Do you want to continue hooking the memory manager?
[Yes] [No]
And CodeGuard is not even enabled in the project options!!
We do NOT have memmgr.lib included within the project, but we do have Use
Dynamic RTL set.
Hitting [No] starts our program without any trouble, but hitting [Yes] generates
some Bad Parameter warnings in CPU code within a CodeGuard log.
How do we remove this CG Warning at the start of our program?
Wiljo.
 

Re:Re: AV on delete operator

Wiljo wrote:
Quote
And CodeGuard is not even enabled in the project options!!
Check all your projects and if it still does it check the BPR and
remove any references to CG32.LIB.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html