[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit

2021-09-04 Thread mailnew4ster at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101933

Paul Jackson  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Paul Jackson  ---
I debugged it a bit more, and I found out that:
1. It's happening when exceptions are involved.
2. It's actually a bug of TDM-GCC.

For details, please see my second comment in the GitHub issue:
https://github.com/jmeubank/tdm-gcc/issues/38#issuecomment-912876481

[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit #38

2021-09-03 Thread mailnew4ster at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101933

--- Comment #3 from Paul Jackson  ---
Maybe I'm missing something, but even this dll crashes for me now. So it seems
like it has nothing to do with global variables or static storage. That sucks,
it means that I just can't use C++ in dlls. Or is it? How come nobody noticed
it before?

I hope that I'm missing something here.

```
#include 

void x()
{
std::vector v;
v.push_back(2);
}
```

[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit #38

2021-09-03 Thread mailnew4ster at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101933

--- Comment #2 from Paul Jackson  ---
I tried to work around the problem, and it's even worse than I expected. You
can replace dll.cc with the following and observe the same crash.

That means that even if I want to do manual memory management with raw
pointers, I can't. Please, consider fixing at least this.

```
#include 

struct {
std::vector v;
} *test;

void x()
{
if (test) {
test->v.push_back(2);
}
}
```

[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit #38

2021-08-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101933

--- Comment #1 from Andrew Pinski  ---
I suspect it is because __cxa_exit is not used such that deconstructors are not
called at unload of the dll time.