[Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

Mårten Nordheim marten.nordheim at qt.io
Wed Feb 5 08:59:00 CET 2020


Any chance we could get a stacktrace from the crash? Or does your build of Qt not have any symbols?

Mårten

________________________________
Fra: Interest <interest-bounces at qt-project.org> på vegne av maitai <maitai at virtual-winds.org>
Sendt: Tuesday, February 4, 2020 7:42:50 PM
Til: Interest at qt-project.org <Interest at qt-project.org>
Emne: Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x


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

    HRESULT hres;

    // Initialize COM.

    hres =  CoInitializeEx(0, COINIT_MULTITHREADED);

    if (FAILED(hres))

    {

        qWarning() << "Failed to initialize COM library. "

            << "Error code = 0x"

            << hex << hres << endl;

        return QByteArray();

    }

So this part is now broken in 5.14.x. If I put COINIT_APARTMENTTHREADED as a parameter for CoInitializeEx it seems to work again but I have to check a few other things before being 100% sure.

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...

Philippe Lelong (a bit confused by all that, I must admit).



Le 04-02-2020 18:17, Rainer Wiesenfarth a écrit :

On Tue, Feb 4, 2020 at 5:18 PM Mårten Nordheim <marten.nordheim at qt.io<mailto:marten.nordheim at qt.io>> 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 indirectly use it so you didn't get a conflict earlier.

[...]


This sounds familiar. We ran into a similar issue with QFileDialog crashing due to the wrong COM threading model being active.

I do not recall the details, but searching for "CLR Thread Attribute" (a linking parameter) may give you some useful information.

Cheers, Rainer

--
Software Engineer | Trimble Imaging Division
Rotebühlstraße 81 | 70178 Stuttgart | Germany
Office +49 711 22881 0 | Fax +49 711 22881 11
http://www.trimble.com/imaging/ | http://www.inpho.de/

Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
Geschäftsführer: Rob Reeder, Jürgen Kesper

_______________________________________________
Interest mailing list
Interest at qt-project.org<mailto:Interest at qt-project.org>
https://lists.qt-project.org/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20200205/e608f914/attachment.html>


More information about the Interest mailing list