public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Hagood <david.hagood@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Re: Strange exception handling behaviour with dlopen()
Date: Tue, 17 Nov 2020 12:56:04 -0600	[thread overview]
Message-ID: <5612854a-bd7f-4626-0bca-080f6faabd0a@gmail.com> (raw)
In-Reply-To: <AM0PR0302MB31880D71D2E10E6354E733CEBFE20@AM0PR0302MB3188.eurprd03.prod.outlook.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1740 bytes --]

You are squarely into "undefined behavior" territory here:


> static int throw314()
> {
>      std::cout << "throw314() called\n" << std::flush;
>      throw 3.14f;
> }
>
> static int throwDuringInitialization = throw314();

You are throwing from a constructor. That's STRONGLY discouraged - it 
leads to undefined behavior, as you cannot tell how much of an object 
has been constructed, and thus how much can be safely torn down. It's 
far better to have a function to be called after the constructor has 
completed, and let that function throw if needed, so that you can be 
sure all objects are fully constructed (and thus can be destructed) 
before the exception can cause problems.


> int main() {
>
>      try {
>          void* handle = dlopen("throw_in_static_init.so", RTLD_LAZY);
>          std::cout << "Lib loading: " << (handle ? "successfull" : "failed") << "\n";
>      } catch (float f) {
>          std::cout << "Exception caught in main function: " << f << std::endl;
>      }

It's also a really bad idea to throw an exception from within a C 
function (dlopen). Ideally, any function with extern "C" linkage should 
avoid any C++ specific concepts, like exceptions. The compiler won't 
have done all the homework in dlopen for things like unwinding the stack 
in an exception, since exceptions don't exist in C.


If you need your shared library to do some initialization that 
potentially could fail, you should probably define a C++ function within 
the shared library that does the exception, and will be called after the 
dlopen completes successfully.


I suggest you get the Scott Meyer books "Effective C++" and “More 
Effective C++” and read them thoroughly.


[-- Attachment #1.1.2: OpenPGP_0x5B9DC79986207D69.asc --]
[-- Type: application/pgp-keys, Size: 3217 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2020-11-17 18:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 17:40 Nemeth, Laszlo02
2020-11-17 18:56 ` David Hagood [this message]
2020-11-17 19:16   ` Stefan Ring
2020-11-17 19:17   ` Jonathan Wakely
2020-11-17 19:25     ` David Hagood
2020-11-17 20:12       ` Jonathan Wakely
2020-11-17 20:44     ` Florian Weimer
2020-11-18 11:54 Nemeth, Laszlo02
2020-11-22 17:32 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5612854a-bd7f-4626-0bca-080f6faabd0a@gmail.com \
    --to=david.hagood@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).