Dear all,
After debugging a little, it appears that in order:
- QProgressDialog destructor is called
- Then QProgressDialog::setValue(slot) is called by the connection from
BackgroundFileWorker::progressChanged(int) signal
This means the slot is called after the dialog was destroyed. It was
Den 23-01-2014 10:15, Etienne Sandré-Chardonnal skrev:
Dear all,
I'm tracking a bug since a few days, which happens at the end of file
saving in my app. It saves using a separate thread, while the GUI
displays a modal progress dialog. The app crashes in the QProgressDialog
destructor, and
Hi Bo,
Thanks for helping, please read my initial post carefully.
1) I do actually call start(), look at the forelast line of
BackgroundFileWorker::startWriting, both in the paste code, and in the
attached zip
2) run() is empty here because I have stripped down my app (2Mb of code) to
make a
I can't actually do what you suggest because the file writing is done by an
external lib written by me, but which should not have Qt dependencies. Anyway,
that's not the topic here:
If the user can't really do anything during the duration of the save
why not just show them a busy cursor. If
Hi Etienne,
Ok, fair enough.
I just compiled and ran your example with 4.8.5. I don't have 4.8.1
available anywhere. It ran the save dialog without any crashes.
Looks like you have to upgrade to a newer Qt version. Which you really
should do anyway. 4.8.1 is *old*.
If upgrading doesn't work,
Hi everyone!
I save some compressed XML data taking huge sizes such as 1Gb, files saves
can last more than 1 minute. A busy cursor cannot be distinguished from a
frozen app in Windows. But I should not even have to justify myself on this
as this is not the topic here.
I have sent a minimal
On 23 January 2014 20:22, Etienne Sandré-Chardonnal
etienne.san...@m4x.org wrote:
I have sent a minimal crashing example, which might (I'm 99% sure) be
related to a Qt bug, and I'd like interested people to look at the code and
try to understand why it's crashing. Please forget the other stuff
Thanks Bo,
Did you try the save dialog several times? It may take a few times to crash
(2 to 50). I rapidly click on the button then press enter multiple times to
trigger it.
I was just starting compiling 4.8.5 while you were writing this e-mail :)
Sze-Howe : sure!
Cheers,
Etienne
Den 23-01-2014 13:49, Etienne Sandré-Chardonnal skrev:
Thanks Bo,
Did you try the save dialog several times? It may take a few times to
crash (2 to 50). I rapidly click on the button then press enter multiple
times to trigger it.
Yes, and I wasn't able to get the crash.
I was just starting
That bug is really quantic... I tried setting a QTimer to do the
save/accept job automatically, and this doesn't crash anymore :(
4.8.5 compile in progress... let's cross our fingers
2014/1/23 Bo Thorsen bthor...@ics.com
Den 23-01-2014 13:49, Etienne Sandré-Chardonnal skrev:
Thanks Bo,
On 01/23/2014 08:05 AM, Etienne Sandré-Chardonnal wrote:
That bug is really quantic... I tried setting a QTimer to do the save/accept
job
automatically, and this doesn't crash anymore :(
Have you tried running under Valgrind
to see if it has anything to say.
4.8.5 compile in progress...
Nope, as I'm under windows now. But I will undust my valgrind dedicated
linux virtualbox for this... Hoping that the bug happens under linux, which
is far from sure.
I managed to trigger it with a timer and no user interaction, but it takes
more time to crash.
Cheers
2014/1/23
I encountered a similar problem with similar code. My problem was the
following unexpected feature of QProgressDialog::setValue():
Warning: If the progress dialog is modal (see
QProgressDialog::QProgressDialog()),
setValue() callsQApplication::processEvents(), so take care that this does
not
Hmmm
Question to the Qt core experts:
Is it possible that setValue(), by calling processEvents(), executes a
deferred delete event on himself?
Thanks,
Etienne
2014/1/23 Björn Piltz bjornpi...@gmail.com
I encountered a similar problem with similar code. My problem was the
following
Hi,
On Thursday, Thursday 23 January 2014 at 10:15, Etienne Sandré-Chardonnal
wrote:
Here is the only non trivial code that could contain the bug if it's not a
Qt bug. This is a QThread subclass worker doing the file saving (here it
does nothing but this crashes anyway on the QProgressDialog
Hi,
2014/1/23 Konrad Rosenbaum kon...@silmor.de
all signal-slot-connections made inside this function are direct
connections and probably executed in the main thread - did you intend this
or can I assume the timer was supposed to live in the new thread?
It was intended to live in the main
16 matches
Mail list logo
