Non connected signal causes crash

[koahnig]

emitting a signal with a custom object results in following message with a crash:
@
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
@
The signal is not connected to any slot. The custom object does not contain a string object but other template objects (std).
The compiler is MinGw 4.6.2 with Qt 4.8.3.

Has somebody an idea?

[MuldeR]

I think we need some code...

[koahnig]

Thanks for feedback.

The code is quite complex and hard to extract essentials.
BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler.

[lgeyer]

Is it possible that there is an implicit conversion from <code>nullptr</code> to <code>std::string</code> somewhere in your code (which has been silently discarded by MSVC, but is now caught by GCC)?

Does this error occour on GCC 4.7.2 as well? Could be a bug in the standard library of GCC 4.6.2.

[koahnig]

Hi Lukas,
neither a std::string nor a QString around there. The custom class has some custom templates with std::vector internally.
The problem seem to occur in the destructor, but the debugger does not really show it. When the emit is being commented out, the problem disappears. I just did another test with a blind function call and there is no problem either. Possibly a mix of issues with emit playing a role.

Thanks for sharing that there is already a newer version of GCC available. I do not understand why they are hiding the version numbers on the mingw webpage. Does not make sense to me :-(

[MuldeR]

[quote author="koahnig" date="1355929296"]Thanks for feedback.

The code is quite complex and hard to extract essentials.
BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler. [/quote]

From experience, if you suspect there is a bug in third-party code, you quite often find the mistake in your own code, while trying to strip it down to a minimal example. And even if it really is compiler issue, we won't know for sure, unless you have clear example code that triggers the issue...

[koahnig]

[quote author="MuldeR" date="1355951809"][quote author="koahnig" date="1355929296"]Thanks for feedback.

The code is quite complex and hard to extract essentials.
BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler. [/quote]

From experience, if you suspect there is a bug in third-party code, you quite often find the mistake in your own code, while trying to strip it down to a minimal example. And even if it really is compiler issue, we won't know for sure, unless you have clear example code that triggers the issue...[/quote]

Yes, I know. You are using similar words as I have used already in this forum.

Following are the current facts:

• As stated above, the code was running as debug and release compilations of msvc 2005.
• It can be limited to a single emit not leading anywhere.
• The class is in use for a couple of years with only minor changes in the non-complex part. It is a central part of the code and nothing used rarely.
• The class has been used in MinGW 4.4 (the one being part of Qt SDK) at least compilations for some tests. However, the emit was not part of those tests.
• Elimination of the emit and using a blind function call runs smoothly. The question is: does the compiler notice that I am trying to fool it even so it is a debug compilation?

Nothing a 100% conclusive yet in my opinion :-(

At the moment I am following Lukas' hint with the newer version of MinGW 4.7.2 which requires unfortunately a complete recompilation of Qt libs and my code.

[lgeyer]

Yes, MinGW can be quite a bit "'arduous'":http://qt-project.org/wiki/MinGW-64-bit sometimes, especially when it comes to Qt5.

[koahnig]

The exact same thing with MinGW 4.7.2 :-(
The possible requirement to recompile everything once again with another compiler damps a bit my enthusiasm to continue.
In my opinion the problem occurs through the combination of different factors. This makes it hard to blame on any of the pieces involved. Ultimately the emit of Qt is the one drop too much for the barrel.

I have decided to the signal's argument list from "const object & " to a variant of shared pointer. This certainly solves the problem for me.