strange exceptions problem

strange exceptions problem

Post by Chris All » Sat, 03 Nov 2001 15:31:00



Hi,

I'm using exceptions to detect errors during construction of my apps
document objects. And I have a try-catch block like to following to report
errors to the user:

   try {
      new CDocument;
   } catch ( OSStatus error ) {
      PostError( error );
   }

When testing my app, I create as many documents as possible and an
exception occurs when the app runs out of memory - which is successfully
caught etc.

So I close all of the documents, and try to create another one - but I
start to get some strange unmapped memory exceptions, when my document
constructor deletes some objects as its supposed to:
   ie.   CString * docMode = CopyModeFromXMLFile( file );
         if ( docMode->Is( resizableString ) ) {
            ...
         }
         delete docMode;

So I'd like to know if it OK for an app to keep running after an exception
has been caught?

Any suggestions about what can cause a problem like this?

 - Chris

 
 
 

strange exceptions problem

Post by meero » Sat, 03 Nov 2001 23:11:01




Quote:>So I close all of the documents, and try to create another one - but I
>start to get some strange unmapped memory exceptions

That means you have a bug which corrupts memory. An unmapped memory
exception is in no way related to C++ exceptions. You need to figure out
where and how you are corrupting memory, and Spotling (onyx-tech.com)
might be useful.

hth

meeroh
--
Hire me: <http://meeroh.org/hire.html>

 
 
 

strange exceptions problem

Post by Howard Hinnan » Sat, 03 Nov 2001 23:35:18



| Hi,
|
| I'm using exceptions to detect errors during construction of my apps
| document objects. And I have a try-catch block like to following to report
| errors to the user:
|
|    try {
|       new CDocument;
|    } catch ( OSStatus error ) {
|       PostError( error );
|    }
|
| When testing my app, I create as many documents as possible and an
| exception occurs when the app runs out of memory - which is successfully
| caught etc.
|
| So I close all of the documents, and try to create another one - but I
| start to get some strange unmapped memory exceptions, when my document
| constructor deletes some objects as its supposed to:
|    ie.   CString * docMode = CopyModeFromXMLFile( file );
|          if ( docMode->Is( resizableString ) ) {
|             ...
|          }
|          delete docMode;
|
| So I'd like to know if it OK for an app to keep running after an exception
| has been caught?

Yes, it is ok.

| Any suggestions about what can cause a problem like this?

Hard to say without more code.  But perhaps a couple of comments can
move the thought process along...

Unless you've overloaded new to throw an OSStatus, then you're not
catching this exception where you think you are.  new throws a
std::bad_alloc.  That might be causing more stack unwinding than you
have prepared for.

In general, writing exception safe code is easy to get wrong.  Note
that "exception safe" doesn't necessarily mean "doesn't throw", and it
doesn't necessarily mean "rollback semantics".  The basic exception
safety guarantee is simply that objects are left in a consistent and
destructible state.  Herb Sutter's "Exceptional C++" has a chapter on
this subject.  Anyway, it could be that the CDocument constructor (or
any number of methods not shown) is not exception safe, possibly
trashing your heap during stack unwinding.

Could be something unrelated to exceptions.  Try recording the number
of documents you successfully create before the exception fires.  Then
run a test that creates just that number of documents and then deletes
them (before the exception is thrown).  Perhaps another part of the
code is running out of memory from a malloc or NewHandle, but failing
to gracefully handle it.

Just some places to start looking, hope this helps.

--
Howard Hinnant
Metrowerks

 
 
 

strange exceptions problem

Post by David Dunha » Sun, 04 Nov 2001 06:19:25




> So I close all of the documents, and try to create another one - but I
> start to get some strange unmapped memory exceptions, when my document
> constructor deletes some objects as its supposed to:
>    ie.   CString * docMode = CopyModeFromXMLFile( file );
>          if ( docMode->Is( resizableString ) ) {
>             ...
>          }
>          delete docMode;

> So I'd like to know if it OK for an app to keep running after an exception
> has been caught?

Definitely!

My guess is that you're trying to use incompletely constructed objects.
You don't show a try/catch above, but if the delete is in the catch,
there's no guarantee that docMode will have a valid value. You might
want to set it to nil first.

--

http://www.pensee.com/dunham/
    "I say we should listen to the customers and give them what they want."
    "What they want is better products for free." --Scott Adams

 
 
 

strange exceptions problem

Post by Chris Allu » Sun, 04 Nov 2001 09:10:55




Quote:> Hard to say without more code.  But perhaps a couple of comments can
> move the thought process along...

> Unless you've overloaded new to throw an OSStatus, then you're not
> catching this exception where you think you are.  new throws a
> std::bad_alloc.  That might be causing more stack unwinding than you
> have prepared for.

    Yeah, I thought about that. I'll look at overloading new, just to
simplify my code a bit.

Quote:> Could be something unrelated to exceptions.  Try recording the number
> of documents you successfully create before the exception fires.  Then
> run a test that creates just that number of documents and then deletes
> them (before the exception is thrown).  Perhaps another part of the
> code is running out of memory from a malloc or NewHandle, but failing
> to gracefully handle it.

    I have a linked list of my documents and I've found that I wasn't
removing the document properly in its destructor - so I must have been
overwriting some other memory when I used the list.

    It always seems to help when I put my problem into words. Thanks for the
help.

- Chris

 
 
 

strange exceptions problem

Post by Howard Hinnan » Sun, 04 Nov 2001 09:25:08



|     Yeah, I thought about that. I'll look at overloading new, just to
| simplify my code a bit.

Might be easier to switch to catching std::bad_alloc.

|     I have a linked list of my documents and I've found that I wasn't
| removing the document properly in its destructor - so I must have been
| overwriting some other memory when I used the list.

Putting my MSL C++ hat on:  have you tried std::list<CDocument> ?  As
long as ~CDocument() is set up properly, then you don't have as much to
worry about.

| It always seems to help when I put my problem into words. Thanks
| for the help.

Glad to help.  That's what we're here for.

--
Howard Hinnant
Metrowerks

 
 
 

1. _this() generates strange exception

Hi,

I'm trying to get the proxy from a GameImpl through _this() but all I get is
a strange exception. This is the idl code:
interface Server {
  boolean challenge( in Player ply, in Opponent opp, out Game game );

and the c++ code:
(inside challenge function, ServerImpl class)
::KGS::Opponent oppIn;
::KGS::Player_ptr refOut;

GameImpl* newGame = new GameImpl;
::KGS::Game_var gv;
try {
 gv = newGame->_this();
catch( const CORBA::OBJECT_NOT_EXIST& ex ) { cerr << ex << endl; }
catch( const CORBA::SystemException& ex ) { cerr << ex << endl; }
catch( const exception& e ) { cout << "Exception" << endl; }
catch( ... ) { cout << "Unknown exception" << endl; }

All that happens in above is the Unknown exception. What is wrong, I am
using Visibroker by the way.
Thanks!

--

Daniel Lidstr?m
danli97(at)ite.mh.se
http://www.ite.mh.se/~danli97/

62 23' 25" N
17 15' 31" E

2. Quicktime for Windows GPF

3. Strange Exception: org.omg.CORBA.INTF_REPOS

4. Travel Management package required

5. NeXTStation: Exception #3 and Exception #2

6. Servo Question

7. Exceptions in Interrupt Handlers (Exception Message)

8. user ID and password for web pages

9. CORBA user-defined exceptions as Java _unchecked_ exceptions?

10. exceptions && exception objects

11. Strange UNIX or strange IDL?

12. 5.1 problems: norm or exception

13. vxWorks PPC exception handle problem