On Sunday, 9 February 2020 15:09:39 PST Hamish Moffatt wrote:
> Ugh, we used to have this problem all the time in the 5.6 days. It would
> be good if Qt were more fussy about loading plugins from mismatched
> versions
Qt specifically allows loading plugins built with older versions, but not
On 7/2/20 2:21 am, maitai wrote:
I had somewhere an old directory "bearer" containing old dlls from
5.9.1 and qt was loading those instead of 5.14.1
Ugh, we used to have this problem all the time in the 5.6 days. It would
be good if Qt were more fussy about loading plugins from mismatched
Found it, and as expected it was something stupid on my side.
I had somewhere an old directory "bearer" containing old dlls from 5.9.1
and qt was loading those instead of 5.14.1
Sorry all for the trouble, and thanks for your patience with me.
Philippe.
Hmm perhaps one way forward is to move some COM-related code to a new
thread (which is then untarnished by any prior CoInitialize(xxx), either
your QNetworkAccessManager instance or the code somewhere in your
HEADER/SOURCES that causes the crash (in concert with 5.14.1's
Good idea, and I just tried. Unfortunately it still crashes...
Philippe.
Le 06-02-2020 11:21, Henry Skoglund a écrit :
Hi, also since constructing a QNetworkAccessManager() does a
CoInitialize(nullptr), have you tried doing a CoUninitialize() just
before, e.g;
...
QApplication app(argc, argv);
Hi, also since constructing a QNetworkAccessManager() does a
CoInitialize(nullptr), have you tried doing a CoUninitialize() just
before, e.g;
...
QApplication app(argc, argv);
CoUninitialize();
QNetworkAccessManager *inet = new QNetworkAccessManager();
delete inet;
...
On 2020-02-06 08:02,
Have you tried to comment out cleanup of reply objects (QNetworkReply) ?
On Thu, Feb 6, 2020 at 8:49 AM maitai wrote:
>
> I've checked it already, and anyway a QFileDialog is a QWidget and as such
> cannot be created before QApplication (that's what it said when I tried).
>
> Philippe
>
>
>
>
I've checked it already, and anyway a QFileDialog is a QWidget and as
such cannot be created before QApplication (that's what it said when I
tried).
Philippe
Le 05-02-2020 21:20, Henry Skoglund a écrit :
> Hi, maybe you already checked this, but if you have any big wheels like a
> QFileDialog
Hi, maybe you already checked this, but if you have any big wheels like
a QFileDialog declared static, their ctors most likely will run before
main(), i.e. some COM/networking activity could occur before main()
kicks in.
On 2020-02-05 21:10, maitai wrote:
As I said, I now have doubts it
As I said, I now have doubts it comes from COM threading...
I have built a small app with nothing inside, with the same .pro file
exactly (qt modules, libs, etc, in the same order). The only difference
is HEADERS and SOURCES of course, main.cpp being the same at least until
it crashes. No
On 2020-02-05 16:32, maitai wrote:
Hi Rainer,
Unfortunately your suggestion didn't work
I have added in my pro file:
win32:QMAKE_LFLAGS+=/CLRTHREADATTRIBUTE:MTA
and I can see the option in the link command (I also tried the 2 other
possibilities STA and NONE of course), but that does not
Hi Rainer,
Unfortunately your suggestion didn't work
I have added in my pro file:
win32: QMAKE_LFLAGS += /CLRTHREADATTRIBUTE:MTA
and I can see the option in the link command (I also tried the 2 other
possibilities STA and NONE of course), but that does not fix anything.
My feeling is that
[...]
>
That being said, even if I remove this call and all references to WMI code
> and CoInitializeEx (including the links to wbemuuid and ws2_32), it still
> crashes if i do not create QNetworkManager before QApplication...
>
[...]
>
Our experience is that only the first call to
Any chance we could get a stacktrace from the crash? Or does your build of Qt
not have any symbols?
Mårten
Fra: Interest på vegne av maitai
Sendt: Tuesday, February 4, 2020 7:42:50 PM
Til: Interest@qt-project.org
Emne: Re: [Interest] Crash when creating
Thanks all for your help
Further findings:
The message concerning COM failing to initialize comes from our app, and
is in fact there always in 5.14.x (regardless of the issue with
QNetworkManager)
In the very first lines of main.cpp, we call a static function which for
Windows does
On Tue, Feb 4, 2020 at 5:18 PM Mårten Nordheim
wrote:
> It’s likely related to the new network connection monitor inside
> QNetworkAccessManager, which uses COM.
>
> Although that by itself shouldn’t cause any issues and there’s other uses
> of COM inside Qt as well. But perhaps you didn’t
suppose it was bound to conflict with something sooner or later ;(
Apologies for the inconvenience!
Mårten
From: maitai<mailto:mai...@virtual-winds.org>
Sent: tirsdag 4. februar 2020 17:08
To: Interest@qt-project.org<mailto:Interest@qt-project.org>
Subject: Re: [Interest] Crash w
On Tue, Feb 4, 2020 at 6:07 PM maitai wrote:
>
> Thanks Robert and Thiago,
>
> If I create it on the stack instead of on the heap same mystery, i.e if
> I create it before qApp all good, if after it crashes
>
> this works:
> qWarning()<<"test";
> QNetworkAccessManager inet;
>
On Tuesday, 4 February 2020 08:06:12 PST maitai wrote:
> this crashes:
> QApplication app(argc, argv);
> qWarning()<<"test";
> QNetworkAccessManager inet;
> qWarning()<<"after test";
And do I understand correctly that a test application containing that will not
crash?
Then
Thanks Robert and Thiago,
If I create it on the stack instead of on the heap same mystery, i.e if
I create it before qApp all good, if after it crashes
this works:
qWarning()<<"test";
QNetworkAccessManager inet;
qWarning()<<"after test";
QApplication app(argc, argv);
this
On Tue, Feb 4, 2020 at 5:43 PM Thiago Macieira
wrote:
>
> On Tuesday, 4 February 2020 01:45:27 PST coroberti . wrote:
> > Sorry, I meant allocation of QNetworkAccessManager object
> > by new operator (dynamic) versus its allocation on function scope (static).
>
> Instead of static, please use
On Tuesday, 4 February 2020 01:45:27 PST coroberti . wrote:
> Sorry, I meant allocation of QNetworkAccessManager object
> by new operator (dynamic) versus its allocation on function scope (static).
Instead of static, please use automatic storage (no static, no new). Create it
in the stack, after
Sorry, I meant allocation of QNetworkAccessManager object
by new operator (dynamic) versus its allocation on function scope (static).
Kind regards,
Robert
On Tue, Feb 4, 2020 at 11:31 AM maitai wrote:
>
> Thanks Robert,
>
> What do you mean by dynamic allocation versus static? In our app all
Thanks Robert,
What do you mean by dynamic allocation versus static? In our app all our
libs are linked statically, all qt libs are dynamics, I cannot change
that easily.
Philippe.
Le 04-02-2020 09:07, coroberti . a écrit :
Dear Philippe,
Try to change dynamic allocation to static and if
Dear Philippe,
Try to change dynamic allocation to static and if the matters come to order,
there's some memory corruption as my experience.
jm2c
Kind regards,
Robert Iakobashvili
On Tue, Feb 4, 2020 at 10:02 AM maitai wrote:
>
> Hi all,
>
> While the mail list was
Hi all,
While the mail list was broken I did some further experiments:
If I move the creation of QNetworkAccessManager into main.cpp, it also
crashes, but only if I put it after QApplication app(argc, argv);
The funny part being that if I create a QneworkAccessManager before and
just delete
Hi all
I am trying to upgrade from qt5.13.2/MSVC2017 to Qt5.14.1/MSVC2017
In 5.14.1 (and 0) app is crashing on "QNetWorkAccessManager *inetManager
= new QNetWorkAccessManager()", while all is OK in previous Qt versions
I cannot debug this on Windows. I have removed all old dlls etc
27 matches
Mail list logo
