Closed dmik closed 4 years ago
With the fixed HIGHMEM, I can finally use the debug DLL (Qt5WebCd.dll) which enables VLOG and DCHECK macros. With this DLL, the test case fails much earlier:
[0727/235746.185000:FATAL:sys_info_posix.cc(58)] Check failed: false.
I will look at this later.
With some fixes I went further, now it crashes in Qt5Core:
Trap -> 1D4B269C QT5CORE 0001:0026269C qresource.cpp#1401 __ZN19QResourceFileEngine4readEPcx + 8C 0001:00262610 (D:\Coding\qt5\qt5\qtbase\src\corelib\io\qresource.cpp)
036FF7E4 1D488E3D QT5CORE 0001:00238E3D qfiledevice.cpp#463 __ZN11QFileDevice8readDataEPcx + 7D 0001:00238DC0 (D:\Coding\qt5\qt5\qtbase\src\corelib\io\qfiledevice.cpp)
036FF834 1D495D2E QT5CORE 0001:00245D2E qiodevice.cpp#1114 __ZN16QIODevicePrivate4readEPcxb + 1DE 0001:00245B50 (D:\Coding\qt5\qt5\qtbase\src\corelib\io\qiodevice.cpp)
036FF8C4 1D4964ED QT5CORE 0001:002464ED qiodevice.cpp#1063 __ZN9QIODevice4readEPcx + 18D 0001:00246360 (D:\Coding\qt5\qt5\qtbase\src\corelib\io\qiodevice.cpp)
036FF914 0C2863E9 QT5WEBC 0001:000563E9 __ZN15QtWebEngineCore19URLRequestCustomJob11ReadRawDataEPN3net8IOBufferEi + 49 0001:000563A0 (D:\Coding\qt5\qt5\qtwebengine\src\core\net\url_request_custom_job.cpp)
I guess it tries to read some test URL from a resource file which is missing on OS/2.
The above comment relates to https://github.com/bitwiseworks/qtwebengine-os2/issues/4 actually and this issue is fixed by the above commit. Closing it.
Blink is a Chromium web rendering engine (https://www.chromium.org/blink). An attempt to start a Qt WebEngine test case (https://github.com/bitwiseworks/qtwebengine-os2/issues/4) in single process mode via
set QTWEBENGINE_CHROMIUM_FLAGS=--single-process
(see https://github.com/bitwiseworks/qtwebengine-chromium-os2/issues/12#issuecomment-663745918) crashes like this:According to .TRP, it tries to write to a r/o memory block allocated by LIBCn (via DosAllocMemEx I presume). Here is the .TRP excerpt:
Unfortunately, EXCEPTQ doesn't recognize optimized (-O2) GCC 9 stack frames (which don't use EBP at all I guess) and cant follow them. So I can only guess who called
GCInfoTable::EnsureGCInfoIndex
based on the stack contents from TRP (not putting it here as it's an extremely large list).I think it has something to with memory permission bits while doing blink heap management (for which we use DosAllocMem APIs).