[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Review Request 119543: Removed all KDialogs from balooWidgets
From: "Felix Eisele" <felix.eisele () va-solutions ! de>
Date: 2014-07-31 15:38:19
Message-ID: 20140731153819.15440.71815 () probe ! kde ! org
[Download RAW message or body]
--===============6526389223541452807==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Juli 30, 2014, 10:54 vorm., Vishesh Handa wrote:
> > src/tagwidget.cpp, line 180
> > <https://git.reviewboard.kde.org/r/119543/diff/1/?file=294417#file294417line180>
> >
> > Any reason you've combined the too functions? I don't remember why, but there was \
> > a point when it split up.
> > Also, if one really doesn't need it to be split up, then we should probably use a \
> > QScopedPointer instead of deleting it outself.
>
> Felix Eisele wrote:
> i did googling yesterday and i think it is not needed.
> I am not a fan of class members. you didnt see the dataflow.
> We should i use a QScopedPointer?
>
> Thomas Braxton wrote:
> Or you could just make it not a pointer and it cleans itself up.
>
> Felix Eisele wrote:
> Good idea!
>
> Frank Reininghaus wrote:
> No, this is a **very bad** idea. Creating the dialog on the stack as a child of \
> "this" and then executing its nested event loop will cause crashes like the ones \
> that are fixed by https://git.reviewboard.kde.org/r/118858/ . You should use a \
> QPointer for the dialog and delete it after calling exec() and checking that the \
> QPointer is not null.
> See the links that Dominik added in a comment to that review request of mine for \
> further info.
> Thomas Braxton wrote:
> Since the whole purpose of this function is to get a list of tags using a dialog, \
> the dialog must exist when it returns from exec(). Otherwise the whole function is \
> **moot**.
> Frank Reininghaus wrote:
> Unfortunately, you can't really control what happens inside the nested event loop \
> that is started by exec(). Anything can happen in there, including events that \
> cause the deletion of the parent widget of the dialog. This parent widget will then \
> try to delete the dialog, which lives on the stack. This will cause a crash.
> The easiest way to reproduce this is the "quit by D-Bus"-trick, as described in, \
> e.g.,
> https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0
> http://kate-editor.org/2012/04/06/crash-through-d-bus-calls/
> https://bugs.kde.org/show_bug.cgi?id=293863#c13
>
> And even if you say that the user is unlikely to do this D-Bus thing: there are \
> other ways to achieve the same effect, even if they are much harder to reproduce. \
> You really cannot assume that the dialog still exists when exec() returns. \
> Definitely not. Code that assumes this is buggy (even if the Qt docs for QDialog \
> still suggest this approach - maybe I should try to get that changed).
> And no, I am really not making this stuff up. We do get bug reports about crashes \
> that are caused by problems like this. Please do not add new versions of these bugs \
> when modifying code.
> BTW, your statement that "the whole function is **moot**" if the dialog does not \
> exist anymore is wrong. After all, the function cannot know what will happen during \
> exec(). Most of the time, the dialog will still be there, stuff will get done with \
> the tags, and everything is all right. But sometimes, the application will quit \
> during exec(), and then the sole remaining purpose of the function is to return \
> gracefully, without a crash. And this graceful return is prevented by creating the \
> dialog on the stack.
> Thomas Braxton wrote:
> You're right, QPointer it has to be.
>
> Thomas Lübking wrote:
> I don't wanna be a spoil spot, but if you delete a qobject while one of its \
> (heaped) children is in a nested eventloop (ie. you're most likely deleting it from \
> that eventloop), you'll usually hit a segfault just as well - QPointer or not.
> --> If you need to delete sth. and don't know whether you're in a nested loop and \
> "something" might be an ancestor: call ::deleteLater()
>
> In other cases, you'll have to protect _anything_ on the heap that you're gonna \
> access after the nested eventloop exited (esp. "this" and the dialog, but also any \
> other heap data)
> The stack is sane with "this", but as of course increases the memory footprint (ie. \
> not good for large temporary structures)
> The dialog is /usually/ safe when it exits "Accepted", but there's no general \
> guarantee (depends on the dialog class)
> Felix Eisele wrote:
> Ok i see the problem. As a result of that if we use QDialog and check the result in \
> that way we should use always qpointer?
> void TagWidget::slotShowAll()
> {
> QPointer<KEditTagsDialog> dialog = new KEditTagsDialog( selectedTags(), this);
> if (dialog->exec() == QDialog::Accepted) {
> setSelectedTags(dialog->tags());
> emit selectionChanged(selectedTags());
> }
>
> if (dialog){
> dialog->deleteLater();
> }
> }
>
> Thomas Lübking wrote:
> void TagWidget::slotShowAll()
> {
> QPointer<TagWidget> that = this;
> QPointer<KEditTagsDialog> dialog = new KEditTagsDialog(selectedTags(), this);
> if (dialog->exec() == QDialog::Accepted && // this is the critical line. if *this \
> is deleted durig exec(), you lost dialog && that) { // this is the safety check - \
> you need *this and dialog to be still sane setSelectedTags(dialog->tags());
> emit selectionChanged(selectedTags());
> }
> delete dialog; // it's ok to delete NULL and you don't need to defer it since \
> dialog is for sure not an ancestor of *this }
>
> If you want to be really sure, don't parent dialog with *this.
> Since that's not required for memory management (you delete dialog), the only good \
> the parent gets you (and that I can think of) is window transiency. You can gain \
> that with QWindow::setTransientParent(QWindow *parent) in Qt5 In Qt4, using an \
> ApplicationModal dialog might do.
> Alternatively, do simply not use a nested eventloop, ie. set the dialog modal, bind \
> its finished() signal to a slot and then show it.
> Frank Reininghaus wrote:
> I don't think that you need the 'that' QPointer. Felix' proposal looks fine to me.
>
> AFAIK, exec() will never return QDialog::Accepted if the event loop is aborted by \
> the dialog (or both the parent widget and the dialog) being deleted, so the "&& \
> that" part of the if-check is superfluous from my point of view.
> Thomas Lübking wrote:
> As mentioned, "Accepted" /usually/ can be assumed to be safe (for the dialog)
>
> If you want to access members of the calling object and cannot guarantee that it \
> has not been deleted before (ie. your initial concern), protecting *this with a \
> QPointer is required.
>
> Please notice that the new suggestion would not provide any security beyond the \
> stack solution. Putting casual stuff on the stack is anything but ideal, but once \
> more:
> When a QObject dies while one of it's children is in a nested eventloop you will \
> segfault. Stack, Heap, QPointer does not matter.
> Try if you don't believe it.
> On the heap, you'll likely end up somewhere in QApplicationPrivate::dispatch*() \
> accessing a member of the removed child from QEventLoop::processEvents() in \
> QDialog::exec()
Very interesing thinks... i learned very much. thanks Frank and Thomas. I am very new \
in qt and c++. I am a C# Developer about 8 years. ok so me last version I think is \
ok. i will doing so.
- Felix
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119543/#review63489
-----------------------------------------------------------
On Juli 30, 2014, 8:05 nachm., Felix Eisele wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119543/
> -----------------------------------------------------------
>
> (Updated Juli 30, 2014, 8:05 nachm.)
>
>
> Review request for Baloo and Vishesh Handa.
>
>
> Repository: baloo-widgets
>
>
> Description
> -------
>
> Removed all KDialogs from balooWidgets. Removed not needed includes
>
>
> Diffs
> -----
>
> src/kedittagsdialog.cpp c83ce9d
> src/kedittagsdialog_p.h 0bcf744
> src/tagwidget.h 2843acd
> src/tagwidget.cpp f2c3601
> src/tagwidget_p.h 045a185
>
> Diff: https://git.reviewboard.kde.org/r/119543/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Felix Eisele
>
>
--===============6526389223541452807==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/119543/">https://git.reviewboard.kde.org/r/119543/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On Juli 30th, 2014, 10:54 vorm. CEST, <b>Vishesh \
Handa</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="https://git.reviewboard.kde.org/r/119543/diff/1/?file=294417#file294417line180" \
style="color: black; font-weight: bold; text-decoration: \
underline;">src/tagwidget.cpp</a> <span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">bool \
TagWidget::readOnly() const</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2">178</font></th> <td bgcolor="#fdfebc" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="n"><span \
class="hl">d</span></span><span class="o"><span class="hl">-></span></span><span \
class="n"><span class="hl">m_e</span>ditTagsDialog</span> <span class="o">=</span> \
<span class="k">new</span> <span class="n">KEditTagsDialog</span><span \
class="p">(</span> <span class="n">selectedTags</span><span class="p">(),</span> \
<span class="k">this</span> <span class="p">);</span></pre></td> <th \
bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">165</font></th> <td bgcolor="#fdfebc" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span \
class="n"><span class="hl">KE</span>ditTagsD<span class="hl">ialog</span></span><span \
class="o"><span class="hl">*</span></span><span class="hl"> </span><span \
class="n"><span class="hl">d</span>ialog</span> <span class="o">=</span> <span \
class="k">new</span> <span class="n">KEditTagsDialog</span><span \
class="p">(</span><span class="n">selectedTags</span><span class="p">(),</span> <span \
class="k">this</span><span class="p">);</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Any \
reason you've combined the too functions? I don't remember why, but there was a point \
when it split up.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Also, if one really doesn't need it to \
be split up, then we should probably use a QScopedPointer instead of deleting it \
outself.</p></pre> </blockquote>
<p>On Juli 30th, 2014, 11:41 vorm. CEST, <b>Felix Eisele</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">i did \
googling yesterday and i think it is not needed. <br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> I \
am not a fan of class members. you didnt see the dataflow. <br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> We \
should i use a QScopedPointer?</p></pre> </blockquote>
<p>On Juli 30th, 2014, 5:55 nachm. CEST, <b>Thomas Braxton</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Or \
you could just make it not a pointer and it cleans itself up.</p></pre> \
</blockquote>
<p>On Juli 30th, 2014, 8:05 nachm. CEST, <b>Felix Eisele</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Good \
idea!</p></pre> </blockquote>
<p>On Juli 30th, 2014, 9:53 nachm. CEST, <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">No, \
this is a <strong style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">very bad</strong> idea. Creating the dialog on the \
stack as a child of "this" and then executing its nested event loop will cause \
crashes like the ones that are fixed by https://git.reviewboard.kde.org/r/118858/ . \
You should use a QPointer for the dialog and delete it after calling exec() and \
checking that the QPointer is not null.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">See the links that \
Dominik added in a comment to that review request of mine for further info.</p></pre> \
</blockquote>
<p>On Juli 31st, 2014, 12:34 vorm. CEST, <b>Thomas Braxton</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Since \
the whole purpose of this function is to get a list of tags using a dialog, the \
dialog must exist when it returns from exec(). Otherwise the whole function is \
<strong style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">moot</strong>.</p></pre> </blockquote>
<p>On Juli 31st, 2014, 1:44 vorm. CEST, <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Unfortunately, you can't really control what happens inside the nested \
event loop that is started by exec(). Anything can happen in there, including events \
that cause the deletion of the parent widget of the dialog. This parent widget will \
then try to delete the dialog, which lives on the stack. This will cause a crash.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">The easiest way to reproduce this is the "quit by \
D-Bus"-trick, as described in, e.g.,</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: \
inherit;">https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;" /> http://kate-editor.org/2012/04/06/crash-through-d-bus-calls/<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;" /> https://bugs.kde.org/show_bug.cgi?id=293863#c13</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">And even if you say that the user is unlikely to do \
this D-Bus thing: there are other ways to achieve the same effect, even if they are \
much harder to reproduce. You really cannot assume that the dialog still exists when \
exec() returns. Definitely not. Code that assumes this is buggy (even if the Qt docs \
for QDialog still suggest this approach - maybe I should try to get that \
changed).</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">And no, I am really not making this stuff up. We do \
get bug reports about crashes that are caused by problems like this. Please do not \
add new versions of these bugs when modifying code.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">BTW, \
your statement that "the whole function is <strong style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">moot</strong>" if the \
dialog does not exist anymore is wrong. After all, the function cannot know what will \
happen during exec(). Most of the time, the dialog will still be there, stuff will \
get done with the tags, and everything is all right. But sometimes, the application \
will quit during exec(), and then the sole remaining purpose of the function is to \
return gracefully, without a crash. And this graceful return is prevented by creating \
the dialog on the stack.</p></pre> </blockquote>
<p>On Juli 31st, 2014, 3:02 vorm. CEST, <b>Thomas Braxton</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">You're right, QPointer it has to be.</p></pre> </blockquote>
<p>On Juli 31st, 2014, 9:05 vorm. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
don't wanna be a spoil spot, but if you delete a qobject while one of its (heaped) \
children is in a nested eventloop (ie. you're most likely deleting it from that \
eventloop), you'll usually hit a segfault just as well - QPointer or not.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">--> If you need to delete sth. and don't know whether you're in a nested \
loop and "something" might be an ancestor:<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> call \
::deleteLater()</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">In other cases, you'll have to protect \
<em style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">anything</em> on the heap that you're gonna access \
after the nested eventloop exited (esp. "this" and the dialog, but also any other \
heap data)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">The stack is sane with "this", but as of course \
increases the memory footprint (ie. not good for large temporary structures)</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">The dialog is /usually/ safe when it exits "Accepted", but there's no \
general guarantee (depends on the dialog class)</p></pre> </blockquote>
<p>On Juli 31st, 2014, 12:22 nachm. CEST, <b>Felix Eisele</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Ok i \
see the problem. As a result of that if we use QDialog and check the result in that \
way we should use always qpointer?</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">void \
TagWidget::slotShowAll()<br style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;" /> {<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
QPointer<KEditTagsDialog> dialog = new KEditTagsDialog( selectedTags(), \
this);<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;" /> if (dialog->exec() == QDialog::Accepted) {<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;" />
setSelectedTags(dialog->tags());<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" />
emit selectionChanged(selectedTags());<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> }</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;"><div class="codehilite" style="background: \
#f8f8f8"><pre style="line-height: 125%"><span style="color: #008000; font-weight: \
bold">if</span> (dialog){ dialog<span style="color: \
#666666">-></span>deleteLater(); }
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">}</p></pre> </blockquote>
<p>On Juli 31st, 2014, 1:54 nachm. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">void \
TagWidget::slotShowAll()<br style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;" /> {<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
QPointer<TagWidget> that = this;<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
QPointer<KEditTagsDialog> dialog = new KEditTagsDialog(selectedTags(), \
this);<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;" /> if (dialog->exec() == QDialog::Accepted \
&& // this is the critical line. if <em style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">this is deleted durig \
exec(), you lost<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;" /> dialog && that) { // this is the safety \
check - you need </em>this and dialog to be still sane<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;" />
setSelectedTags(dialog->tags());<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" />
emit selectionChanged(selectedTags());<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> }<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
delete dialog; // it's ok to delete NULL and you don't need to defer it since dialog \
is for sure not an ancestor of *this<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> }</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If you want to be really sure, don't parent dialog \
with <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">this.<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> Since that's not \
required for memory management (you delete dialog), the only good the parent gets you \
(and that I can think of) is window transiency.<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> You can gain that \
with QWindow::setTransientParent(QWindow </em>parent) in Qt5<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> In \
Qt4, using an ApplicationModal dialog might do.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Alternatively, do simply not use a nested eventloop, ie. set the dialog \
modal, bind its finished() signal to a slot and then show it.</p></pre> \
</blockquote>
<p>On Juli 31st, 2014, 3:25 nachm. CEST, <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
don't think that you need the 'that' QPointer. Felix' proposal looks fine to me.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">AFAIK, exec() will never return QDialog::Accepted if \
the event loop is aborted by the dialog (or both the parent widget and the dialog) \
being deleted, so the "&& that" part of the if-check is superfluous from my \
point of view.</p></pre> </blockquote>
<p>On Juli 31st, 2014, 3:38 nachm. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">As \
mentioned, "Accepted" /usually/ can be assumed to be safe (for the dialog)</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">If you want to access members of the calling object and cannot guarantee \
that it has not been deleted before (ie. your initial concern), protecting *this with \
a QPointer is required.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Please notice that the new suggestion \
would not provide any security beyond the stack solution.<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
Putting casual stuff on the stack is anything but ideal, but once more:</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">When a QObject dies while one of it's children is in a nested eventloop you \
will segfault. Stack, Heap, QPointer does not matter.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Try \
if you don't believe it.<br style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;" /> On the heap, you'll likely end up \
somewhere in QApplicationPrivate::dispatch*() accessing a member of the removed child \
from QEventLoop::processEvents() in QDialog::exec()</p></pre> </blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Very interesing thinks... i learned very much. thanks Frank and Thomas. I \
am very new in qt and c++. I am a C# Developer about 8 years. ok so me last version I \
think is ok. i will doing so.</p></pre> <br />
<p>- Felix</p>
<br />
<p>On Juli 30th, 2014, 8:05 nachm. CEST, Felix Eisele wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for Baloo and Vishesh Handa.</div>
<div>By Felix Eisele.</div>
<p style="color: grey;"><i>Updated Juli 30, 2014, 8:05 nachm.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
baloo-widgets
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Removed all KDialogs from balooWidgets. Removed not \
needed includes</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/kedittagsdialog.cpp <span style="color: grey">(c83ce9d)</span></li>
<li>src/kedittagsdialog_p.h <span style="color: grey">(0bcf744)</span></li>
<li>src/tagwidget.h <span style="color: grey">(2843acd)</span></li>
<li>src/tagwidget.cpp <span style="color: grey">(f2c3601)</span></li>
<li>src/tagwidget_p.h <span style="color: grey">(045a185)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/119543/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============6526389223541452807==--
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic