Re: [Interest] Crash when signal fires
> On Apr 22, 2020, at 11:19 AM, Thiago Macieira > wrote: > > On Tuesday, 21 April 2020 17:09:45 PDT Ben Haller via Interest wrote: >> Unfortunately, I’m on macOS 10.15.3 and Valgrind is not there yet (I think >> at present they have “preliminary” support for macOS 10.13). > > Then install a Linux VM and use Valgrind there. Valgrind is useful enough to > warrant a VM just for it. Ah, that is a good idea! I shall do so. >> I suspect this is a really dumb question, but what is “ASAN”? Is that >> another Valgrind-like tool? > > -fsanitize=address in your compilation and linking flags. > > With qmake, you can also get that by doing: > > CONFIG += sanitizer sanitize_address Aha, very interesting. I’ll try this as well. Thanks for the help. Cheers, -B. Benjamin C. Haller Messer Lab Cornell University ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when signal fires
> On Apr 22, 2020, at 11:17 AM, Thiago Macieira
> wrote:
>
> On Tuesday, 21 April 2020 16:44:19 PDT Ben Haller via Interest wrote:
>>connect(qApp, ::focusChanged, [this]() {
>> updateUIEnabling(); });
>
> Your object probably outlived QApplication.
Other way around, right?
> Add a third argument of "this" to the connect() call.
Yes, Giuseppe D’Angelo set me on the right path on this, and I’ve just gone
through all the connect() calls in my app and made them all safe. Thanks!
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when signal fires
On Tuesday, 21 April 2020 17:09:45 PDT Ben Haller via Interest wrote: > Unfortunately, I’m on macOS 10.15.3 and Valgrind is not there yet (I think > at present they have “preliminary” support for macOS 10.13). Then install a Linux VM and use Valgrind there. Valgrind is useful enough to warrant a VM just for it. > I suspect this is a really dumb question, but what is “ASAN”? Is that > another Valgrind-like tool? -fsanitize=address in your compilation and linking flags. With qmake, you can also get that by doing: CONFIG += sanitizer sanitize_address -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when signal fires
On Tuesday, 21 April 2020 16:44:19 PDT Ben Haller via Interest wrote:
> connect(qApp, ::focusChanged, [this]() {
> updateUIEnabling(); });
Your object probably outlived QApplication.
Add a third argument of "this" to the connect() call.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when signal fires
> On Apr 21, 2020, at 7:51 PM, Giuseppe D'Angelo via Interest
> wrote:
>
> On 4/22/20 1:44 AM, Ben Haller via Interest wrote:
>> Hi folks. I’m seeing something weird that I don’t understand. I have a
>> connection defined for the main window of my Qt Widgets app, like so:
>> connect(qApp, ::focusChanged, [this]() {
>> updateUIEnabling(); });
>> I’m seeing a 100% reproducible crash as a result of this. When the
>> focusChanged signal fires, I end up in updateUIEnabling() as expected, but I
>> immediately crash because something about the state of things is corrupted;
>> the immediate symptom, according to the debugger, is that the ui pointer for
>> my main window is equal to 0x1 (yuck). I try to access a button,
>> ui->playOneStepButton, and it crashes. As I said, 100% reproducible.
>> The weird thing is that this does*not* happen if I change the connect
>> statement to this:
>> connect(qApp, ::focusChanged, this,
>> ::updateUIEnabling);
>> Now, 100% of the time, there is no problem, no crash, and my app chugs along
>> happily. No other code changes involved. I can literally flip this connect
>> definition back and forth in my code and go from 100% crashing to 100% fine.
>
> A quick checklist:
>
> 0) I hope threads are not involved (you're not really allowed to do any GUI
> work from any other thread).
No threads.
> 1) Never use the 3-arguments connect(). If you want to use the lambda, pass
> "this" as 3rd parameter and lambda as fourth. Why: if "this" has been
> destroyed, the first version won't disconnect automatically and crash. The
> second will disconnect and not crash.
>
> More info: https://stackoverflow.com/a/27954502
Ah, I see! I was assuming it was my first window’s focusChanged connection
that was crashing, but it was probably the second (closed) window’s connection
that was crashing, in fact, because the window was gone but the connection
remained.
> 2) ASAN, Valgrind and friends will help you locate the source of the crash if
> it's due to memory corruption. Use them.
Unfortunately, I’m on macOS 10.15.3 and Valgrind is not there yet (I think at
present they have “preliminary” support for macOS 10.13).
I suspect this is a really dumb question, but what is “ASAN”? Is that
another Valgrind-like tool?
Well, in any case, I think you have explained my bug. Thanks very much!
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when signal fires
On 4/22/20 1:44 AM, Ben Haller via Interest wrote:
Hi folks. I’m seeing something weird that I don’t understand. I have a
connection defined for the main window of my Qt Widgets app, like so:
connect(qApp, ::focusChanged, [this]() { updateUIEnabling();
});
I’m seeing a 100% reproducible crash as a result of this. When the focusChanged
signal fires, I end up in updateUIEnabling() as expected, but I immediately crash
because something about the state of things is corrupted; the immediate symptom,
according to the debugger, is that the ui pointer for my main window is equal to
0x1 (yuck). I try to access a button, ui->playOneStepButton, and it crashes.
As I said, 100% reproducible.
The weird thing is that this does*not* happen if I change the connect
statement to this:
connect(qApp, ::focusChanged, this,
::updateUIEnabling);
Now, 100% of the time, there is no problem, no crash, and my app chugs along
happily. No other code changes involved. I can literally flip this connect
definition back and forth in my code and go from 100% crashing to 100% fine.
A quick checklist:
0) I hope threads are not involved (you're not really allowed to do any
GUI work from any other thread).
1) Never use the 3-arguments connect(). If you want to use the lambda,
pass "this" as 3rd parameter and lambda as fourth. Why: if "this" has
been destroyed, the first version won't disconnect automatically and
crash. The second will disconnect and not crash.
More info: https://stackoverflow.com/a/27954502
2) ASAN, Valgrind and friends will help you locate the source of the
crash if it's due to memory corruption. Use them.
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Crash when signal fires
[ I realized I ought to supply the crash backtrace; I have appended it below my
signature. ]
Hi folks. I’m seeing something weird that I don’t understand. I have a
connection defined for the main window of my Qt Widgets app, like so:
connect(qApp, ::focusChanged, [this]() { updateUIEnabling(); });
I’m seeing a 100% reproducible crash as a result of this. When the
focusChanged signal fires, I end up in updateUIEnabling() as expected, but I
immediately crash because something about the state of things is corrupted; the
immediate symptom, according to the debugger, is that the ui pointer for my
main window is equal to 0x1 (yuck). I try to access a button,
ui->playOneStepButton, and it crashes. As I said, 100% reproducible.
The weird thing is that this does *not* happen if I change the connect
statement to this:
connect(qApp, ::focusChanged, this,
::updateUIEnabling);
Now, 100% of the time, there is no problem, no crash, and my app chugs along
happily. No other code changes involved. I can literally flip this connect
definition back and forth in my code and go from 100% crashing to 100% fine.
I’m pretty new to Qt and maybe I’m just being clueless somehow; but I thought
that the two definitions above would be essentially identical in their effect.
Why does the first one crash? Note that it works fine in general; it seems to
crash specifically when I open a *second* main window (which makes its own
connection to focusChanged in the same way), and then close that second main
window. Now the first main window’s connection is somehow unhappy, and the
next time I trigger the focusChanged() signal, boom. It’s as if the connection
for the second window somehow interferes with the connection for the first
window, and closing the second window leads to a corruption in the connection
state.
Naturally, I am now nervous about using the first type of connection anywhere
in my code, since I don’t understand what the issue is. Can anyone shed light
on this?
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.sticksoftware.QtSLiM0x0001003c84b1
QtSLiMWindow::updateUIEnabling() + 17 (QtSLiMWindow.cpp:1589)
1 com.sticksoftware.QtSLiM0x0001003d224e
QtPrivate::FunctorCall, QtPrivate::List<>, void,
QtSLiMWindow::init()::$_3>::call(QtSLiMWindow::init()::$_3&, void**) + 14
(qobjectdefs_impl.h:146)
2 org.qt-project.QtCore 0x00010228ca95 void
doActivate(QObject*, int, void**) + 1157 (memory:2597)
3 org.qt-project.QtWidgets0x0001013d67de
QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) + 510
4 org.qt-project.QtWidgets0x00010140f6fd
QWidget::setFocus(Qt::FocusReason) + 637 (qwidget.cpp:6356)
5 org.qt-project.QtWidgets0x0001013d7dd8
QApplication::setActiveWindow(QWidget*) + 1160
6 org.qt-project.QtWidgets0x0001013d8333
QApplicationPrivate::notifyActiveWindowChange(QWindow*) + 51
(qapplication.cpp:2101)
7 org.qt-project.QtGui0x000101a35623
QGuiApplicationPrivate::processActivatedEvent(QWindowSystemInterfacePrivate::ActivatedWindowEvent*)
+ 675 (qguiapplication.cpp:2438)
8 org.qt-project.QtGui0x000101a12cc3 bool
QWindowSystemInterfacePrivate::handleWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
+ 115 (qwindowsysteminterface.cpp:106)
9 libqcocoa.dylib 0x0001063511ee
QCocoaWindow::windowDidBecomeKey() + 238 (qcocoawindow.mm:1194)
10 org.qt-project.QtCore 0x0001022648d6
QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument) const + 1270
11 libqcocoa.dylib 0x000106354830 invocation function
for block in qRegisterNotificationCallbacks() + 1936 (qcocoawindow.mm:131)
12 com.apple.Foundation0x7fff3860cfab -[__NSObserver
_doit:] + 296
13 com.apple.CoreFoundation0x7fff35f8c35f
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
14 com.apple.CoreFoundation0x7fff35f8c2f3
___CFXRegistrationPost1_block_invoke + 63
15 com.apple.CoreFoundation0x7fff35f8c268
_CFXRegistrationPost1 + 372
16 com.apple.CoreFoundation0x7fff35f8bebe
___CFXNotificationPost_block_invoke + 97
17 com.apple.CoreFoundation0x7fff35f5b7e2
-[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1575
18 com.apple.CoreFoundation0x7fff35f5ac82 _CFXNotificationPost
+ 1351
19 com.apple.Foundation0x7fff385e0a22
-[NSNotificationCenter postNotificationName:object:userInfo:] + 59
20 com.apple.AppKit
[Interest] Crash when signal fires
Hi folks. I’m seeing something weird that I don’t understand. I have a
connection defined for the main window of my Qt Widgets app, like so:
connect(qApp, ::focusChanged, [this]() { updateUIEnabling();
});
I’m seeing a 100% reproducible crash as a result of this. When the
focusChanged signal fires, I end up in updateUIEnabling() as expected, but I
immediately crash because something about the state of things is corrupted; the
immediate symptom, according to the debugger, is that the ui pointer for my
main window is equal to 0x1 (yuck). I try to access a button,
ui->playOneStepButton, and it crashes. As I said, 100% reproducible.
The weird thing is that this does *not* happen if I change the connect
statement to this:
connect(qApp, ::focusChanged, this,
::updateUIEnabling);
Now, 100% of the time, there is no problem, no crash, and my app chugs along
happily. No other code changes involved. I can literally flip this connect
definition back and forth in my code and go from 100% crashing to 100% fine.
I’m pretty new to Qt and maybe I’m just being clueless somehow; but I thought
that the two definitions above would be essentially identical in their effect.
Why does the first one crash? Note that it works fine in general; it seems to
crash specifically when I open a *second* main window (which makes its own
connection to focusChanged in the same way), and then close that second main
window. Now the first main window’s connection is somehow unhappy, and the
next time I trigger the focusChanged() signal, boom. It’s as if the connection
for the second window somehow interferes with the connection for the first
window, and closing the second window leads to a corruption in the connection
state.
Naturally, I am now nervous about using the first type of connection anywhere
in my code, since I don’t understand what the issue is. Can anyone shed light
on this?
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
