Crash when using KIdentityManagement::IdentityManager

[Volker Krause]

On Mittwoch, 14. April 2021 19:04:46 CEST David Faure wrote:
> On mardi 13 avril 2021 20:21:21 CEST Volker Krause wrote:
> > On Dienstag, 13. April 2021 17:47:47 CEST Carl Schwan wrote:
> > > Hello folks,
> > > 
> > > I have been trying to implement a mail client based on Akonadi
> > > for the PinePhone. I'm currently getting blocked by a weird
> > > crash in KIdentityManagement::IdentityManager.
> > > 
> > > The code can be found here:
> > > https://invent.kde.org/carlschwan/quickmail/-/blob/master/src/main.cpp#L
> > > 46
> > > 
> > > valgrind/gdb tells me that the d pointer of the IdentityManager is
> > > inaccessible when calling constEnd/Begin(). But then adding the exact
> > > same
> > > code as a test case in KIdentityManagement, it works without any crash.
> > > 
> > > Does anyone with a bit more experience in C++ can help me?
> > 
> > Summary of the discussion on chat:
> > 
> > It's an ABI issue on methods returning a QVector::[const_]iterator, and
> > KIdentityManagement being built with QT_STRICT_ITERATORS enabled (via KF
> > default settings), while the application didn't have that set.
> 
> Ouch! We didn't think of that, when enabling QT_STRICT_ITERATORS.
> 
> > I'm wondering now what the lesson for ABI compatibility in general is from
> > this:
> > * do not use QVector iterator types in public API?
> 
> This seems like the safest option indeed.
> 
> > do we even do that in KF?
> 
> Not really. All I found was 3 typedefs, but they are not used in the API (or
> anywhere in app code, in fact) kconfig/src/core/kcoreconfigskeleton.h:   
> typedef QHash<QString, KConfigSkeletonItem *>::Iterator DictIterator;
> kio/src/core/kacl.h:typedef QList<ACLUserPermissions>::iterator
> ACLUserPermissionsIterator; kio/src/core/kacl.h:typedef
> QList<ACLGroupPermissions>::iterator ACLGroupPermissionsIterator;
> > * do not set QT_STRICT_ITERATOR? what if the consuming code has it set
> > though?
> 
> Right, the mismatch can happen both ways, so this wouldn't help.
> 
> > * only allow QVector iterators in public API inline code (so it
> > entirely follows QT_STRICT_ITERATOR as set on the outside)?
> 
> Do we have a 100% guarantee that the compiler will inline the code,
> even with optimizations disabled? I thought this was only a hint?

Different meaning of inline. What I am referring to is code that does not even 
have exported symbols (templates being the obvious/extreme case, but this 
applies to code in header files in general). With no existing symbol there is 
no choice for the compiler either way. This is different from suggesting the 
compiler to inline a function body at the call site. Whether or not that 
happens in the consuming binary is irrelevant here, that just affects how many 
copies there are going to be in there.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210414/7cd51344/attachment.sig>