<table><tr><td style="">davidedmundson added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4301" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D4301#inline-17175" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">subdiff</span> wrote in <span style="color: #4b4d51; font-weight: bold;">statusnotifieritemsource.cpp:472</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p style="padding: 0; margin: 8px;">This spins its own event loop which is dangerous when dealing with QML</p></blockquote>

<p style="padding: 0; margin: 8px;">Since the event loop is part of the service, isn't the QML shielded from it anyway? The QML code connects only to the job finished signal in the end, which is emitted again by the job's/service's main thread.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p style="padding: 0; margin: 8px;">Since the event loop is part of the service, isn't the QML shielded from it anyway? The QML code connects only to the job finished signal in the end, which is emitted again by the job's/service's main thread.</p></blockquote>

<p style="padding: 0; margin: 8px;">If only :)</p>

<p style="padding: 0; margin: 8px;">We spawn a new event loop here, from inside this event loop we continue processing animations, mouse, DBus whatever. <br />
During this, we might end up deleting the SNI and implicitly this datasource.</p>

<p style="padding: 0; margin: 8px;">We then finish this method, potentially 30 seconds after we started, and come out of this line.</p>

<p style="padding: 0; margin: 8px;">"this" is now a danging pointer and the m_statusNotifierItemInterface->interface on the next line seg faults.</p>

<p style="padding: 0; margin: 8px;">This is a nice simple explanation of a simpler version of the same problem:<br />
<a href="https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0" class="remarkup-link" target="_blank" rel="noreferrer">https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0</a></p>

<p style="padding: 0; margin: 8px;">only in QML it's even worse! Even if you did guard against it, QMLEngine then returns with the nicely wrapped JS value to a javascript context that doesn't exist - and there's no way to guard that.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4301" rel="noreferrer">https://phabricator.kde.org/D4301</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>subdiff, Plasma, davidedmundson<br /><strong>Cc: </strong>broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas<br /></div>