Bug 359709 - Windows version crashes after two keystrokes in composer's recipients
Summary: Windows version crashes after two keystrokes in composer's recipients
Status: RESOLVED FIXED
Alias: None
Product: trojita
Classification: Applications
Component: Desktop GUI (other bugs)
Version First Reported In: git
Platform: Microsoft Windows Linux
: NOR crash
Target Milestone: ---
Assignee: Trojita default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-23 17:22 UTC by Jan Kundrát
Modified: 2016-02-29 20:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kundrát 2016-02-23 17:22:00 UTC
Reproduced on the builds from the CI, using Server 2012 R2.
Comment 1 Thomas Lübking 2016-02-23 17:35:11 UTC
Crashes in wine (as well?) - the backtrace isn't terribly helpful :-(

Unhandled exception: privileged instruction in 32-bit code (0x6df4654a).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:6df4654a ESP:0098caec EBP:0098cc68 EFLAGS:00010292(  R- --  I S -A- - )
 EAX:6df46548 EBX:03eabf10 ECX:044bad50 EDX:0446fcd8
 ESI:044bad50 EDI:044bad28
Stack dump:
0x0098caec:  66b2538c 0098cb2c 00000009 0001005e
0x0098cafc:  00000001 00000002 00000001 030414a4
0x0098cb0c:  044e7008 00000002 00000000 00000000
0x0098cb1c:  7bcd6000 03ec0000 044e6ff8 0098cb2c
0x0098cb2c:  0098ccbc 00000005 7bc3e916 03040000
0x0098cb3c:  7bc3ea46 0098cb60 66b9f5e8 66c07eb4
Backtrace:
=>0 0x6df4654a in qwindows (+0x8654a) (0x0098cc68)
  1 0x00443d86 in trojita (+0x43d85) (0x0098cd38)
  2 0x0064b0d1 in trojita (+0x24b0d0) (0x0098ce28)
  3 0x02c23b84 in qt5widgets (+0x153b83) (0x0098ce78)
  4 0x02c2aa59 in qt5widgets (+0x15aa58) (0x0098cf78)
0x6df4654a: repne insl	%dx,%es:(%edi)
Comment 2 Jan Kundrát 2016-02-24 16:42:27 UTC
Here's a better backtrace (installing that env on a Windows VM was a bit painful):

1	QObject::disconnect	qobject.cpp	2932	0x6b904e26	
2	Gui::ComposeWidget::completeRecipients	ComposeWidget.cpp	1254	0x45cd4d	
3	call	qobjectdefs_impl.h	501	0x5b07a1	
4	call<QtPrivate::List<QString const&>, void>	qobjectdefs_impl.h	520	0x5b07a1	
5	QtPrivate::QSlotObject<void (Gui::ComposeWidget:: *)(QString const&), QtPrivate::List<QString const&>, void>::impl	qobject_impl.h	143	0x5b07a1	
6	QtPrivate::QSlotObjectBase::call	qobject_impl.h	124	0x6ba520d1	
7	QMetaObject::activate	qobject.cpp	3698	0x6b907163	
8	QMetaObject::activate	qobject.cpp	3578	0x6b906b8e	
9	QLineEdit::textEdited	moc_qlineedit.cpp	417	0x2b7b1be3	
10	QLineEditPrivate::_q_textEdited	qlineedit_p.cpp	111	0x2b7a9d40	
11	QLineEdit::qt_static_metacall	moc_qlineedit.cpp	252	0x2b7b1403	
12	QMetaObject::activate	qobject.cpp	3713	0x6b907249	
13	QMetaObject::activate	qobject.cpp	3578	0x6b906b8e	
14	QWidgetLineControl::textEdited	moc_qwidgetlinecontrol_p.cpp	258	0x2b99c79f	
15	QWidgetLineControl::finishChange	qwidgetlinecontrol.cpp	711	0x2b82f3c3	
16	QWidgetLineControl::insert	qwidgetlinecontrol.cpp	265	0x2b82df67	
17	QWidgetLineControl::processKeyEvent	qwidgetlinecontrol.cpp	1888	0x2b834929	
18	QLineEdit::keyPressEvent	qlineedit.cpp	1693	0x2b7ae2e1	
19	QWidget::event	qwidget.cpp	8708	0x2b6940cb	
20	QLineEdit::event	qlineedit.cpp	1456	0x2b7ada6f	
...	<More>

It points to the following part:

1251     // if two jobs are running, first was started before second so first should finish earlier
1252     // stop second job
1253     if (firstJob && secondJob) {
1254         disconnect(secondJob, nullptr, this, nullptr);
1255         secondJob->stop();
1256         secondJob->deleteLater();
1257         secondJob = 0;
1258     }
1259     // now at most one job is running

As a random observation, the settings dialog is able to show various plugins, but the default settings (which use QSettings for passwords) lead to a message similar to "waiting for password" being shown all the time in the IMAP config. Hence my speculation -- maybe this is somehow related to plugins being broken?
Comment 3 Jan Kundrát 2016-02-24 16:59:04 UTC
...and this is printed on stderr, btw:

Starting C:\Users\IEUser\Documents\build-trojita-Desktop_Qt_5_5_1_MinGW_32bit2-Debug\trojita.exe...
QObject::connect: signal not found in Plugins::PluginManager
QObject::connect: signal not found in Plugins::PluginManager
Error: Registering IPC instance failed: Not connected to D-Bus server
QObject::connect: signal not found in Plugins::AddressbookCompletionJob
QObject::connect: signal not found in Plugins::AddressbookCompletionJob
QObject::connect: signal not found in Plugins::AddressbookCompletionJob
QObject::connect: signal not found in Plugins::AddressbookCompletionJob

-> yes, plugins are definitely broken for some reason.
Comment 4 Jan Kundrát 2016-02-25 08:36:35 UTC
And the reason was wrong exporting of symbols. Patch which fixes this is at https://gerrit.vesnicky.cesnet.cz/r/619, and a new binary installer at http://ci-logs.kde.flaska.net/binaries/trojita/win32/check/Trojita-Setup-619-7a176fc251a5461098d7272a4969c469.exe .

@msjasinski, could you please give it a try?
Comment 5 msjasinski 2016-02-25 21:26:24 UTC
I tested the new built with the same file and the bug seems to be fixed (no crash and the file is sent and received without filename change)!

Thank you very much!
Comment 6 Jan Kundrát 2016-02-29 20:28:26 UTC
Git commit 2fd5a59886f7720a4ba8321bb816cf94053fb153 by Jan Kundrát.
Committed on 26/02/2016 at 10:57.
Pushed by gerrit into branch 'master'.

Fix import of plugin symbols on Windows

On Windows, one has to mark the code which lives in a DLL as
Q_DECL_EXPORT when building that DLL, and Q_DECL_IMPORT when using it
from outside of the shared DLL.

The older version of this code was semi-correct -- the plugins
themselves were built in a mode where the PluginManager's methods were
accessed as Q_DECL_IMPORT, the trojita_plugins.dll was built with a
correct Q_DECL_EXPORT. So far so good. However, the main application was
accessing the PluginManager using the default of Q_DECL_EXPORT. This is
a problem because trojita.exe needs to be built with PluginManager being
marked as Q_DECL_IMPORT since the PluginManager itself lives in that
shared DLL.

When the support for shared plugins is disabled (why do we want to
support it in the first place, btw?), there's no reason to use any
dllexport/dllimport bits, so we disable that through a #cmakedefine.

When using the libtrojita_pluygins, though, we have to distinguish if
the PLUGINMANAGER_EXPORT is supposed to expand to Q_DECL_EXPORT or
Q_DECL_IMPORT. Q_DECL_EXPORT should be used only iff the current
translation unit is going to end up in libtrojita_plugins shared
library, otherwise it must be marked as Q_DECL_IMPORT.

The plugins themselves do not have to be marked in any special way due
to the way how the Qt5 plugins work. Their loading and instantiation is
handled by Qt's own code. We do not have direct access to the plugins'
header files or their implementation, so there's no reason to export
their own symbols.
Change-Id: I2128e5d06426e64f9cc3dee0dd2cf510a0769817

M  +3    -0    CMakeLists.txt
M  +5    -5    src/Plugins/AddressbookPlugin.h
M  +2    -2    src/Plugins/PasswordPlugin.h
M  +11   -9    src/Plugins/PluginJob.h
M  +1    -1    src/Plugins/PluginManager.h
A  +1    -0    src/configure-plugins.cmake.in

http://commits.kde.org/trojita/2fd5a59886f7720a4ba8321bb816cf94053fb153