[Interest] Suppressing Q_ASSERT on release builds

Jani Tykka jtykka at broadsoft.com
Wed Jan 11 09:58:29 CET 2017


...Continuing (accidentally sent the mail)

The fact that delegated_frame_node.cpp is asserting in release build
is an issue in Qt that should be fixed. I ended up explicitly removing
Q_ASSERTs from that file. We have been receiving these crash reports
to our system from customers. The assert location is:

2016-11-22 08:41:04,791 QtLogger [0x700000117000] FATAL ASSERT:
"texture->hasAlphaChannel() || !quadNeedsBlending" in file
/opt/jenkins/workspace/qt5_git_osx_64/qt5/qtwebengine/src/core/delegated_frame_node.cpp,
line 382

Next we'll see what happens when that assert is not triggered, will it
cause issues somewhere else? Any ideas about that? There is no way to
reproduce the issue.

Thanks

On Wed, Jan 11, 2017 at 10:52 AM, Jani Tykka <jtykka at broadsoft.com> wrote:
> On Tue, Jan 10, 2017 at 5:35 PM, Thiago Macieira
> <thiago.macieira at intel.com> wrote:
>> Em terça-feira, 10 de janeiro de 2017, às 15:23:32 PST, Jani Tykka escreveu:
>>> It seems that QT_NO_DEBUG doesn't get defined when 3rd party libraries
>>> are built. Which means that if any 3rd party component includes
>>> qglobal.h will then end up defining Q_ASSERT in a way which is not
>>> desired for release builds.
>>
>> Are you talking about 3rdparty components that are used inside Qt? Which one
>> is including qglobal.h?
>>
>
> Yes, in qtbase:
>
> In file included from src/hb-blob.cc:32:
> In file included from src/hb-private.hh:33:
> In file included from ./config.h:25:
> In file included from ../../../include/QtCore/qatomic.h:1:
> In file included from
> ../../../include/QtCore/../../src/corelib/thread/qatomic.h:34:
> In file included from ../../../include/QtCore/qglobal.h:1:
>
>>> If I explicitly define precompiler macro during "configure" then that
>>> will be seen by 3rd party components.
>>>
>>> I think this is problem in Qt build system. QT_NO_DEBUG should end up
>>> to all components being build. Any thoughts, ideas, experience on this
>>> area? How to get this fixed? Of course I can define QT_NO_DEBUG in
>>> configure, but then in case when I want to build with
>>> --debug-and-release I'd need to make to separate builds to allow
>>> assertions on with debug builds.
>>
>> QT_NO_DEBUG is defined if you compile in release mode. It's right there in
>> qt.prf:
>>
>> CONFIG(release, debug|release):DEFINES += QT_NO_DEBUG
>>
>> The macro wouldn't get defined if the .pro file does CONFIG -= qt. Can you point
>> to which one(s) those are?
>>
>
> Actually I was confused about the above hb-blob compiled without
> QT_NO_DEBUG and started blaming that qtwebengine does the same, but
> then I found that there is a bit different story:
>
> src/core/delegated_frame_node.cpp asserts in release builds since:
>
> #undef __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES
> #define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
> #endif
>
> Then see https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AssertMacros.h
>
>
>
>
>
>
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> --
> Jani Tykkä
> Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com



-- 
Jani Tykkä
Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com

-- 


This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.



More information about the Interest mailing list