QT4.1.1 and later fail on windows 2000

[dimitri]

Mmmh... I've checked this issue with the relevant developer and the code compiled with -msse shouldn't be called unless a run-time test finds SSE is supported (which shouldn't be the case for your processor).

I really don't know. Are you using a standard MinGW instalaltion? Does the compiler generate i386 code by default as expected?

Also the stack trace looks broken, which doesn't help identifying the problem :-(

[Spockmeat]

I'm just using the standard mingw that was isntalled with qt. How would I check that it builds i386 code by default? Everything about the install is as clean as I can make it.

When I remove the -march=i586 and remove the -msse from that .pri file you said, I get all sorts of compile errors. Way more than will even fit in the command window. Here's the first few lines of the error output.

In file included from painting/qdrawhelper_x86.cpp:30:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/include/mmintrin.h:34:3: #error "MMX instruction set not enabled"
In file included from painting/qdrawhelper_x86.cpp:32:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/include/xmmintrin.h:34:3: #error "SSE instruction set not enabled"
painting/qdrawhelper_x86.cpp:55: error: `__m64' does not name a type
painting/qdrawhelper_x86.cpp:63: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:68: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:74: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:79: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:88: error: `m64' does not name a type

In file included from painting/qdrawhelper_x86.cpp:30:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/include/mmintrin.h:34:3: #error "MMX instruction set not enabled"
In file included from painting/qdrawhelper_x86.cpp:32:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/include/xmmintrin.h:34:3: #error "SSE instruction set not enabled"
painting/qdrawhelper_x86.cpp:55: error: `__m64' does not name a type
painting/qdrawhelper_x86.cpp:63: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:68: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:74: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:79: error: `m64' does not name a type
painting/qdrawhelper_x86.cpp:88: error: `m64' does not name a type

To copy to clipboard, switch view to plain text mode 

Actually, if you do the same thing, remove the -msse from the compile options in the painting.pri file, I'll bet compiling it will fail for you as well. If I put that -msse flag back in everything will compile fine again, but it won't work obviously unless I stick that -march=i586 back in again.

[dimitri]

When I remove the -march=i586 and remove the -msse from that .pri file you said, I get all sorts of compile errors.

My wrong. Since src/gui/painting/qdrawhelper_x86.cpp contains explicit SSE instructions, it will obviously not compile without -msse. However these SSE instructions will not be executed unless SSE support has been detected, which shouldn't be the case on your machine.

Chances are this is a gcc bug. However in order to get really sure the problem is not caused by errors in the SSE detection code, you could modify src/gui/painting/qdrawhelper.cpp to totally disable SSE:

static uint detectCPUFeatures() {
    return 0
}

static uint detectCPUFeatures() {
    return 0
}

To copy to clipboard, switch view to plain text mode 

Or leave src/gui/painting/qdrawhelper_x86.cpp out of the build process altogether by removing it from src/gui/painting/painting.pri.

I don't know how willing you are to spend time on this...

You could also send a bug report to the MinGW project:
MinGW bugs
To send a helpful bug report, see also:
default target architecture?

[Spockmeat]

Ya, I can spend a little time on this. Is there anything specific you want me to try? I'll throw that code to disable the sse check in and see what happens, again it'll be a day before the compile completes though. And this will be without the -march=i586 command. So essentially it should be a fresh build with only the SSE check disabled.

I read through that bug report, but I didn't see anyone asking for any more specific information than what is already provided. Would be interesting to see if any on that list try building Qt4.1.2 on an old processor.

[dimitri]

Some more specific information is asked in the thread. Generally speaking, you provide detailed and accurate information. Make sure you specify all of these in a bug report:

• Which exact programs crash? The Qt build process executes some Qt programs such as moc and uic. If the Qt build process succeeds, it means these programs didn't crash. Is that corrrect? Do moc and uic crash when run after Qt has been installed? What about rcc, lrelease and lupdate? Do only GUI programs crash?
• How exactly was Qt built?
• Which exact version of MinGW is this? Where was it downloaded from?
• In every bug report, specify the exact processor model and OS version. You did that right, but others did not - P-II or P-Pro is not detailed enough. The information can be found in the Dr. Watson log file, it would be useful to always attach this log file.
• The Dr. Watson log posted here shows a very broken stack trace that cannot be used to debug the problem. Is this always the case?

Otherwise, I don't expect much from disabling SSE detection. That's just to be 100% sure the problem is elsewhere...

If the problem is with gcc as I believe it is, try building Qt with the latest version of gcc. Which version of gcc are using right now? I understand you've using the MinGW package bundled with Qt? It's not really up-to-date anymore, I'd try a more recent version of MinGW.

[Spockmeat]

The compile process does indeed finish properly. moc and uic are fine, as are rcc, lupdate and lrelease. If I try to start any gui application it crashs right away, whether it is my own program or designer or any of the examples.

Qt build process:
Install 4.1.2 source from install file (also downloads and installs mingw at this time). configure -plugin-sql-mysql -I c:\mysql\include -L c:\mysql\lib -fast
make

Mingw version:
Downloaded during the install process automatically, I think it comes from trolltech's servers or something. mingw32-gcc --version displays:
mingw32-gcc (GCC) 3.4.2 (mingw-special)
Which is the version listed under the Current section of the downloads. I could get the candidate version (3.4.5) and try that if you want.

CPU version:
Intel Celeron 433MHz family 6, model 6, stepping 5, revision mB0 (pentium II based)
OS: Windows 2000 sp4 with all critical updates applied.

Dr. Watson log:
I don't know what the log is suppose to look like, or what you mean when you say it shows a broken stack. All the entries relating to Qt crashs look almost exactly the same.


If disabling the SSE check doesn't work, I'll try the newer version of gcc tomorrow.

[dimitri]

Mingw version:
Downloaded during the install process automatically, I think it comes from trolltech's servers or something. mingw32-gcc --version displays:
mingw32-gcc (GCC) 3.4.2 (mingw-special)
Which is the version listed under the Current section of the downloads. I could get the candidate version (3.4.5) and try that if you want.

There are two pages, the Download page on mingw.org and the File Release System page on SourceForge.net. I stiil haven't understood which one is authoritative... Anyway, gcc 3.4.2 should be good enough, it's best to stay with Current and not mess with Candidate for now.

Dr. Watson log:
I don't know what the log is suppose to look like, or what you mean when you say it shows a broken stack. All the entries relating to Qt crashs look almost exactly the same.

As far as I know, the log should indicate where the program crashes. What I see in the log doesn't make any sense though.

It's interesting that only GUI programs crash, not uic or moc. It's also interesting that these crashes have only been reproduced on Windows 2000 so far, maybe the crash is related to the classical Windows style and threfore doesn't occur on Windows XP. You could also try building Qt with other styles in addition to the Windows style such as the CDE style (is that possible with Qt/Win open source edition?) and see if you can reproduce the problem with other styles. Just a shoot in the dark, I really don't have a clear idea of what could be going wrong...

Also is another copy of Qt installed on your system? Maybe they're interfering somehow?

[Spockmeat]

whelllllll....

what would you say if I told you after compiling everything from scratch, with that SSE check disabled, that everything works just fine now.

Looks to me like that is the issue.

[dimitri]

whelllllll....

what would you say if I told you after compiling everything from scratch, with that SSE check disabled, that everything works just fine now.

Thanks for looking into this! So you're positive that the only thing that has changed is that the SSE check is disabled? How did you disable it exactly? As follows?

static uint detectCPUFeatures() {
    return 0;
}

static uint detectCPUFeatures() {
    return 0;
}

To copy to clipboard, switch view to plain text mode 

Are you able to reproduce the problem again by putting the original detectCPUFeatures() back into qdrawhelper_x86.cpp and running make again? I'm sorry for asking all these questions again and again, but I need to be certain this is the cause of the crash.

So it looks like detectCPUFeatures() is wrong. We still have to find how it is wrong. I may have to create a small standalone program that calls detectCPUFeatures() and outputs the results. Then I'll ask you to run it on your machine.

I'll look into this.

[Spockmeat]

Yes, in that detectCPUFeatures() method I stuck a return 0; and commented out the rest. I am quite confident that is the problem, I just set the function back to the original, changed to the gui directory and just ran make. The output is libQtGui4.a, and when I try to run any gui programs they crash outright. Setting the function back to

1.
      static uint detectCPUFeatures() {
   2.
          return 0;
   3.
      }

1.
      static uint detectCPUFeatures() {
   2.
          return 0;
   3.
      }

To copy to clipboard, switch view to plain text mode 

and recompiling results in everything working properly again.

Actually, the function detectCPUFeatures() is located in qdrawhelper.cpp, not qdrawhelper_x86.cpp.

[dimitri]

This has been fixed this this morning in Oslo. Just change the source code of function detectCPUFeatures() in file src/gui/painting/qdrawhelper.cpp from:

"pushf\n"
         "pop %%eax\n"
         "xor %%ebx, %%eax\n"
         "jz 1f\n"
 
         "mov $0x00000001, %%eax\n"
         "cpuid\n"
         "mov %%edx, %0\n"
         "1:\n"
         "pop %%ebx\n"
        : "=r" (result)
        :
        : "%eax", "%ecx", "%edx"

"pushf\n"
         "pop %%eax\n"
         "xor %%ebx, %%eax\n"
         "jz 1f\n"

         "mov $0x00000001, %%eax\n"
         "cpuid\n"
         "mov %%edx, %0\n"
         "1:\n"
         "pop %%ebx\n"
        : "=r" (result)
        :
        : "%eax", "%ecx", "%edx"

To copy to clipboard, switch view to plain text mode 

to:

"pushf\n"
         "pop %%eax\n"
         "xor %%edx, %%edx\n"
         "xor %%ebx, %%eax\n"
         "jz 1f\n"
 
         "mov $0x00000001, %%eax\n"
         "cpuid\n"
         "1:\n"
         "pop %%ebx\n"
         "mov %%edx, %0\n"
        : "=r" (result)
        :
        : "%eax", "%ecx", "%edx"

"pushf\n"
         "pop %%eax\n"
         "xor %%edx, %%edx\n"
         "xor %%ebx, %%eax\n"
         "jz 1f\n"

         "mov $0x00000001, %%eax\n"
         "cpuid\n"
         "1:\n"
         "pop %%ebx\n"
         "mov %%edx, %0\n"
        : "=r" (result)
        :
        : "%eax", "%ecx", "%edx"

To copy to clipboard, switch view to plain text mode 

Does it work for you?

[Spockmeat]

yes indeed it seems to work
Much thanks for your help.