By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,018 Members | 930 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,018 IT Pros & Developers. It's quick & easy.

Static destructors in udb

P: n/a

Hello,

I am debugging a C++ application that was ported from PostgreSQL to
DB2 UDB (v8.1.0.112) on Linux and have run across a problem. We have
a singleton object that handles connection pooling, creating
connections, etc. This object is declared static to ensure
destructors run before the program exits. The problem occurs when our
destructors run as the program is exiting. They attempt to free up DB2
resources that DB2 apparently has already freed and we receive a
segmentation fault.

If I remove 'static' from the singleton object, all *seems* to be
well. Can I depend on DB2 always freeing up all handles, connections,
etc before a program exits? If not, is there a way I can prevent
their cleanup code from running, or delay it until after our static
destructors have executed? Is the DB2 cleanup code run through it's
own static destructor, a signal handler or some other mechanism?

Thanks in advance for any help!

Donna Lenharth

Feb 6 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
do************@gmail.com wrote:
>
Hello,

I am debugging a C++ application that was ported from PostgreSQL to
DB2 UDB (v8.1.0.112) on Linux and have run across a problem. We have
a singleton object that handles connection pooling, creating
connections, etc. This object is declared static to ensure
destructors run before the program exits. The problem occurs when our
destructors run as the program is exiting. They attempt to free up DB2
resources that DB2 apparently has already freed and we receive a
segmentation fault.

If I remove 'static' from the singleton object, all *seems* to be
well. Can I depend on DB2 always freeing up all handles, connections,
etc before a program exits? If not, is there a way I can prevent
their cleanup code from running, or delay it until after our static
destructors have executed? Is the DB2 cleanup code run through it's
own static destructor, a signal handler or some other mechanism?
I don't know for sure, but I'd think that DB2 installs an exit handler.

Have you verified in a debugger where exactly the segfault occurs? I would
think that even if DB2 freed up some resources before, you should not see a
segfault.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Feb 6 '07 #2

P: n/a
The seg fault occurs inside libdb2.so on the call the SQLDisconnect.
If I comment out the call to SQLDisconnect, a seg fault occurs on the
call to SQLFreeHandle.

Is there a way I can determine if the resource has already been freed
before attempting to free it again?

I don't know for sure, but I'd think that DB2 installs an exit handler.

Have you verified in a debugger where exactly the segfault occurs? I would
think that even if DB2 freed up some resources before, you should not see a
segfault.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany- Hide quoted text -

- Show quoted text -

Feb 6 '07 #3

P: n/a
do************@gmail.com wrote:
The seg fault occurs inside libdb2.so on the call the SQLDisconnect.
If I comment out the call to SQLDisconnect, a seg fault occurs on the
call to SQLFreeHandle.

Is there a way I can determine if the resource has already been freed
before attempting to free it again?
You could try to collect a CLI trace. That should contain the information
about disconnects.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Feb 6 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.