Slot Not Being Called In RELEASE Build Mode, DEBUG is fine (Windows and Linux)

[bob2oneil]

I have an application that works fine in DEBUG mode under both Windows and Linux. The development tools are Qt Creator and MSVC under Windows, and Qt Creator and Eclipse under Linux.

Consistent with both platforms, in RELEASE mode only, several signals are not being received by their corresponding slots. I have diagnostic code in both DEBUG and RELEASE modes that will indicate if the connection call fails, will indicate when the signal is generated, and when the slot receives the signal. From what I observe, the connection is successful, the signal gets generated, but no slot is called as a result.

I have no warning messages from Qt during DEBUG mode.

I have performed rebuilds, deleted the binaries, re-ran qmake, clean, etc. with the same behavior. Again, no problems with the DEBUG mode, just RELEASE.

Does anyone have any idea of why the RELEASE mode libraries might have a problem that is not true with the DEBUG ones?

Is there a good signal/slot spy tool available or recommended that will support release mode debugging?

I looked at a Qt App called Conan, which may be of benefit for signal/spy diagnostics.

I am using Qt version 4.7.2, Open Source version

[nikhilqt]

In MSVC enable Debugging, Generate Debug Info such that you can debug the Release mode.

and also post your signal, slot signatures.

[bob2oneil]

I think this may be resolved, I cleaned out physically all build directories, ran Clean, qmake, etc. However, I am interested in any type of runtime signal/slot spy, or perhaps a trace log that is operative in both debug and release modes (similar to
a TraceWin application that I have used in the past).

[_Stefan]

There is always a difference between debug and release.
Sometimes, your debug version does do something you expected, but does not work in release.
This just means, your code is still wrong, but due to debug stuff, it covers up the error. In example when using pointers/memory that is invalid.
Debug versions tend to keep used memory longer valid, while in release versions, your memory is already made invalid/reused.

But if cleaning and running qmake worked, there probably was something wrong with your moc stuff

I guess you can use QDebug to create the basis of a trace thingie!

[squidge]

Conan is the only signal spy I know of and it appears to work on release mode applications as the signal information will still be there regardless.

[bob2oneil]

Thanks for everyone's inputs. I was fairly confident that my code was solid, although I certainly understand the nature of debug vs release in general, and how behaviors and timing can change. I think my problem was with MOC generation, and the simply project related
implementations such as "Clean All" and rerun qmake did not at first resolve the problem. I wanted to make sure that there was not something inherent to the release builds of the Qt DLL's that would explain the strange behavior. I think the moral of this thread is that
if behavior changes between releases, make sure you try very hard to regenerate everything. I actually made a few changes in my project's preprocessor contents, the side effect was complete regen occurred.

Thanks for the confirmation on Conan, sounds like a good spy for both DEBUG and RELEASE modes.

More broadly, what I have done in previous developments (not necessarily Qt), is have a trace window that I could use for both debug and release mode diagnostics.

MSVC 16-bit has a separate log window, I created my own for MFC Win32. Is there any Qt app that anyone is aware of for runtime logging and diagnostics for say program call stack info?

For example, I have used a product called SmartInspect for .NET and Java based applications.