Qt 4.6

[Silvan Scherrer]

move to 4.6 code base

[Dmitry A. Kuminov]

I'll start with this task as we may get some new printer code so that porting it twice is pointless.

[Dmitry A. Kuminov]

Imported new sources from the [qt-everywhere-opensource-src-4.6.1.tar.gz ​http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.1.tar.gz] archive from Nokia. Quite a huge bunch of updates -- more than 40 MB of new sources (Most don't (yet) relate to the current OS/2 port state though). ​Here is what's new in Qt 4.6 from the functional point of view.

Note that the only thing from the original archive I skipped when importing is the /doc/html and /doc/qch subdirectories as they contain the documentation generated from /doc/src which makes no sense to store it in SVN. All other imports will be done in the same way.

Also note that I branched the current trunk to /branches/4.5.1. Please use this branch (e.g. checkout or switch to ​http://svn.netlabs.org/repos/qt4/branches/4.5.1) if you need to access SVN within the next couple of days while I will be fixing the trunk build after merging the 4.6.1 sources into it (which will definitely break something). Or just wait until I finish merging and make sure trunk builds again.

[Dmitry A. Kuminov]

Adopted qmake, core and network modules to 4.6.1 changes.

With GUI, it turned out to be more work than I planned, and it's also more code to compile than before so I will finish it tomorrow.

[Dmitry A. Kuminov]

Adopted GUI 4.6.1 (so that the trunk should build now again) but get some assertions when starting any application. Investigating.

[Dmitry A. Kuminov]

Closing this task since the trunk builds completely now.

[Dmitry A. Kuminov]

I will update to 4.6.2; there doesn't seem to be any changes that would require porting.

[Dmitry A. Kuminov]

Note that I merged in the 4.6.2 changes to the trunk in r651 but haven't fully built it yet so there may be temporary build problems.

[Dmitry A. Kuminov]

Analyzing the crashes of the browser demo (which I used to test webkit) shows that some parts of networking are broken somehow. This may be a 4.6.x regression as I noticed a lot of changes over there and even had to adopt the network module to the new API when merging 4.6.1 in.

This needs to be resolved before the release.

[Dmitry A. Kuminov]

I fixed the network data transfer slowdown in r665:666 but there's still a crash in demos/browser, investigating further...

[Dmitry A. Kuminov]

Regarding the emxomf problem, I created this ticket: ​http://svn.netlabs.org/libc/ticket/220. The patched emxomf binary is attached to the ticket as well.

[Dmitry A. Kuminov]

Plugins are somehow broken now. Either due to dllexport or to the new emxomf.exe. Investigating.

[Dmitry A. Kuminov]

A quick check shows that gcc442 generates different N_EXP entries for data objects as compared to gcc335: it prepends them with an asterisk (*) which apparently breaks emxomf.exe (note that the one from Paul does neither work). As a result, none of the Qt plugins can export the qt_plugin_query_verification_data array and Qt can't detect they are plugins.

[Dmitry A. Kuminov]

I wasn't entirely correct, see ​http://svn.netlabs.org/libc/ticket/220 again. The new patch and the binary are attached there as well. Plugins work again now.

[Dmitry A. Kuminov]

Hmm, in the pre-final release build, the SQL plugin doesn't work here. Crap.

[Dmitry A. Kuminov]

This is totally weird. First of all, gcc does *never* define NDEBUG on its own actually (the article I read was wrong and now it's obviously clear why), bit the sqlite plugin *does* define it explicitly in release builds. As a result, it has "release" in the Qt build key while everything else has "debug" there. Also, the latter is wrong by itself because in the release build the build key must contain always "release".

I fixed this in r692 by using the QT_NO_DEBUG which should always be defined for all code built in release mode. This requires the full library rebuild. So no release before 17.03. I will start a build now and will work on Lucide tomorrow while it builds.

[Dmitry A. Kuminov]

Found another problem: CLucene doesn't always seem to build the correct index and sometimes cannot find a term that is definitely there, or vice versa, gives pages in the results pane that don't contain the searched term. This may be related to the fact that we switched it from wide char to normal char (due to bogus wcscmp and friends in kLIBC). I will look closer at it tomorrow.

[Dmitry A. Kuminov]

Yet another problem: an application started with QProcess can't read from its stdin if QProcess sets up stderr redirection to a pipe. It looks very strange but 100% reproducible here using the help/remotecontrol example: if line #1183 in qprocess_os2.cpp is commented out, remote control works, otherwise it doesn't Both the debug and the release builds. Needs to be investigated before the release too.

[Dmitry A. Kuminov]

And after some starts it crashes in PMMERGE which means it's impossible to debug with the debugger (PM will hang). Crap.

[Dmitry A. Kuminov]

Horay, now I can debug such complex cases. Well, not interactively debug them of course but at least get the stack trace with symbols (and we can't do anything else even in idbug anyway due to the lack of complete HLL support in WLINK). What is more interesting is that the information necessary for debugging can also be easily gathered by the end user that experiences a crash and sent back to us for analysis. Furthermore, this will also work for release builds.

Gathering the debug information is as easy as executing the following command before starting a crashing appication:

procdump on /L:X:\

where X:\ is the path to store process dumps to.

After this command, any LIBC-based process that crashes due to an unhandled exception will create a file X:\PDUMP.nnn which can be then opened using the PMDF utility and analyzed.

The more tricky part was to get symbols for our DLLs. The problem is that we use Watcom that generates .MAP files incompatible with ILINK and as a result IBM MAPSYM doesn't work on them. So I had to write a converter from Watcom .MAP to IBM .MAP format (which is then passed to MAPSYM). But the results are worth it. This is what I get for the above crash in PMMERGE (non-debuggable otherwise):

005b:1e47443b 00000003 008fe018 1e46958c 008fdc3c  
005b:1e4695f9 00000003 008fe018 1e46958c 1e467dd4  
005b:1e469553 0000000b 008fde3c 00000000 00000000  
005b:1e468473 185bba90 0000000b 008fde3c 1e4684ad  
005b:1e4718d3 0000000b 008fddcc 008fde3c 00000005  
005b:1c02a2aa 008fdff4 008fff84 008fe018 008fdebc [DOSCALL1 _xcptExecuteUserExceptionHandler + 46] 
005b:1c029ed0 008fdff4 008fff84 008fe018 008fdebc [DOSCALL1 _xcptR3ExceptionDispatcher + 88] 
005b:1c029d54 008fdff4 008fe018 1d3e0053 03120924 [DOSCALL1 DOS32R3EXCEPTIONDISPATCHER + 5c] 
005b:00000000 0000000e 008fdff4 008fe018 c0000005  
005b:1d5f7307 010001fd 00ebffe0 008fe6f4 00000004 [QTGUID4 __FPU_CW_GpiDrawBits$w$H2qhQzVkTb6PrBeF3 + 3b] 
005b:1d77f517 010001fd 00ebffe0 008fe6f4 00000004 [QTGUID4 __ZN20QRasterWindowSurface5flushEP7QWidgetRK7QRegionRK6QPoint + 265] 
005b:1d782854 00c7fec8 008ffbe8 00baab44 00baab64 [QTGUID4 __ZNK18QTextureGlyphCache11glyphMarginEv$w$3YFdYNVKGb6p6Bpw4 + 296] 
005b:1d787273 008ffbe8 00baab44 00c7fec8 008ffbe8 [QTGUID4 __ZN19QWidgetBackingStore4syncEv + e3f] 
005b:1d783176 00baab40 00000000 00000000 00c80620 [QTGUID4 __ZN19QWidgetBackingStore8endPaintERK7QRegionP14QWindowSurfaceP14BeginP + 5c] 
005b:1d787156 00baab40 008fe9a8 00c7fec8 008fe9a4 [QTGUID4 __ZN19QWidgetBackingStore4syncEv + d22] 
005b:1d78642b 00baab40 008feb78 008ffbe8 008feadc [QTGUID4 __ZN19QWidgetBackingStore4syncEP7QWidgetRK7QRegion + 17b] 
005b:1d51ab04 00baab40 008ffbe8 008feb78 1d4a55ec [QTGUID4 __ZN14QWidgetPrivate16syncBackingStoreERK7QRegion + 5e] 
005b:1d55ca2e 00ac7140 008feb78 00000000 1d531ffa [QTGUID4 __ZN9QETWidget19translatePaintEventERK5_QMSG + 32c] 
005b:1d559079 008ffbe8 008febe3 008fec70 00000000 [QTGUID4 QtWndProc + 8be] 
005b:1e932056 80000260 00000023 00000000 00000000 [PMMERGE SendMsg + 266] 
005b:1e9476e7 1c753b38 00000000 1c75c02c 00000001 [PMMERGE WIN32UPDATEWINDOW + 3b] 
005b:1d55909e 80000260 008fee4f 008feedc 01000231 [QTGUID4 QtWndProc + 8e3] 
005b:1e932056 80000260 0000004f 01000231 008ff064 [PMMERGE SendMsg + 266] 
005b:1e939dc7 8000025b 1c758076 00000000 b2000831 [PMMERGE WinFrameWndProc + 75f] 
005b:1f163de9 8000025b 00000023 00000000 00000000  
005b:1d559f0a 8000025b 00000023 00000000 00000000 [QTGUID4 QtFrameProc + 369] 
005b:1e932056 8000025b 00000023 00000000 00000000 [PMMERGE SendMsg + 266] 
005b:1e9455dc 1c758000 00000001 1c75c02c 1c75c02c [PMMERGE _WinSetMultWindowPos + 15c] 
005b:1e94ebad 1c77e100 00000004 ffffffff 00000000 [PMMERGE WIN32SETMULTWINDOWPOS + 89] 
005b:1e93a1c5 8000025b 1c758076 1c77e624 00000000 [PMMERGE WinFrameWndProc + b5d] 
005b:1f163de9 8000025b 00000055 1c77e624 00000000  
005b:1d559f0a 8000025b 00000055 1c77e624 00000000 [QTGUID4 QtFrameProc + 369] 
005b:1e932056 8000025b 00000055 1c77e624 00000000 [PMMERGE SendMsg + 266] }}}

Keep in mind that by default PROCDUMP enables the dumps globally so every crashed process will create one (this may be fine tuned using extended command line options, see CPREF). To disable dumping, just do
{{{
procdump off
}}}

I will write an article in the Wiki about this (for end users).

[Dmitry A. Kuminov]

The nasty crash in PMMERGE is fixed in r698.

[Dmitry A. Kuminov]

The QProcess problem is fixed in r700.

[Dmitry A. Kuminov]

The full text search problem in CLucene is fixed in r703 (it was the _ASCII mode indeed).

[Dmitry A. Kuminov]

I think this ticket is outdated. We have more specific tickets for the 4.6 problems we know of.