The International Simutrans Forum

As per the title, win GDI on Windows 7. Won't even get as far as pak selection screen, no error message. r5898 works fine.

Same for SDL on Win7.

I just built r5899 on my own, and it starts up just fine on Win 7. Maybe something is wrong with the build you are using.

I used the version from the nightly server. I only rarely compile the program myself.

However, since the only change in the code between r5898 an r5899 appears to be the info on the version number (111.4 instead of the wrong 111.0) I don't understand why it doesn't run after being compiled by the nightly server...

Does it fail loading the demo game. Some nightlies saved a wrong number of the savegame version.

No. It crashes immediately - before opening any dialog. Both SDL and GDI 5899 from the nightly server. 5898 is fine. And 5899 self compiled is fine.

5902 still won't start (just nothing visible happens, doesn't even create a simu.log when started with / -log 1 debug  - which also works perfectly up to 5898.)

Oh, and even a clean new install does not help.

MAybe that is due to a server update? My mingw build fails with the old mingw with pthreads.

With nightly builds r5903 on WXP, I get the crash, too. However, a self-compiled r5903 (GDI 32 bit) works. (I assume that I build with the right revision, because the revision number is derived.)

Does the nightly build server do clean builds or incremental builds? If the latter, then someone should force a rebuild of everything.

The Server make a new build, no incl. build.

Only Windows have the Problem? Not Linux or Apple?

P.S. wich includes do you use for sdl??

Edit:
Could somebody Test a new Version?
http://www.wernieman.de/sim-test-2012-09-09.exe (http://www.wernieman.de/sim-test-2012-09-09.exe)
Is Windows-GDI in a new mingw32

Quote from: wernieman on September 07, 2012, 06:17:11 AM
Only Windows have the Problem? Not Linux or Apple?

P.S. wich includes do you use for sdl??

Could somebody Test a new Version?
http://www.wernieman.de/sim-test-2012-09-09.exe

Sorry, I can only test on Windows, and this new executable crashes as well. Here, I use MSVC++ 2007 and can only compile the GDI version with it, but I have an old Mingw+SDL on another PC, yet no time today.

Shid ... it is a new mingw32-Cross-Compiler ..... I don´t know, why it crash ....

Do you use spezial dll´s? or a new "clean" Simutrans-direktory??

Removing default.sve did not help.
When starting with MSVC (months ago), I had to supply pthread2 (pthreadVC2.dll etc.; Prissi mentioned this) separately to be able to build and run ST.

Mhhh ..... but that was MSCV and not mingw32 ......

I don´t know how to solfe the Problem .... because, I don´t get a Problem when I compile ....

What is this supposed to do - endless repetitions of "add         byte ptr [eax],al "?

...
007DDEA5  add         byte ptr [eax],al
007DDEA7  add         byte ptr [eax],al
007DDEA9  add         byte ptr [eax],al
007DDEAB  add         byte ptr [eax],al
...
007DDFFD  add         byte ptr [eax],al
007DDFFF  add         byte ptr [eax],al
007DE001  add         byte ptr [eax],al
007DE003  add         byte ptr ds:[5049B8h],dh

Anyway, it crashes at the last line.

Quote from: wernieman on September 07, 2012, 12:51:32 PM
Shid ... it is a new mingw32-Cross-Compiler ..... I don´t know, why it crash ....

Which version of gcc and binutils? I also use mingw32, but compile for Window on Windows.

Quote from: whoami on September 07, 2012, 03:30:21 PM
What is this supposed to do - endless repetitions of "add         byte ptr [eax],al "?

After taking a quick glance in Intel's manual, it seems that add byte ptr [eax],al is what you get when disassembling bytes full of zeros.

Here is the Information:
cross-mingw32/gcc-4.6.3
cross-mingw32/binutils-2.22.90
cross-mingw32/mingw-runtime-3.20
cross-mingw32/w32api-3.17.2

For the Linux 32Bit, I use the same gcc-Version.

For the Linux64Bit: 4.5.4
For Apple: 4.0.1

I upgraded my mingw32 to gcc 4.6.2 and binutil 2.22.1, the newest I could find. When I just compiled a new executable and tried to run that, it crashed immediately, but when I also upgraded the DLLs (which I intentionally skipped), it started up fine. However, the nightlies I found appear to be statically linked, so DLL version mismatch shouldn't be the issue.

When I tried using starting up both GDI and SDL nightly in GDB, i get errors at about the same place as whoami, but the machine code is slightly different between them and whoami's listing. A hexadecimal number starting with 504 is curiously present in all three.

Edit:
Looks like the memory address that crashes isn't even supposed to be executable code. That explains the odd instructions: they're not.

Was the build environment changed between August 27th and 30th? It's hardly imaginable that the change of rev. 5899 makes the difference, but how about compiling rev. 5898 with the current Mingw setup?
It may be the case that the listed components are not compatible in this combination. (I have found a Mingw bug (see 1 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291) and 2 (http://sourceforge.net/apps/trac/mingw-w64/changeset/4156)) with similar symptoms, but it's old and the fix is supposed to be included in this case, but there are many more bugs to review, the problem may even be very new.)

I strongly suspect pthreads. With my old (3.4.5) Mingw I cannot egnerate any useful version. Only with bleeding edge Mingw (not the stable!) simutrans would not crash with pthreads. If the server compiles with MULTI_THREADS=1 fine, then pthreads is the one to blame.

I tried to enable the multithread option with gcc 4.6.2, and Simutrans started up just fine with both MULTI_THREADS=1 and MULTI_THREADS=4. I used dynamic linking, though.

Are nightlies built with debug information included? When I tried to debug them, it didn't appear so. That could be useful also.

I've been using a Dec 2011 install (whatever was latest at that time) without issue. Native, not cross compiler though. Pthreads has been fine. Includes:
gcc-4.6.2-1
binutils-2.22-1
mingwrt-3.20
w32api-3.17-2
libpthreadgc-2.9.0-mingw32-pre-20110507-2

Just updated to the latest. Same as above except:
gcc-4.7.0-1
mingwrt-3.20-2

Still works.
Any custom settings in the Makefile or config.default?

FYI,
Linux/gcc 4 Version: 111.4-5899 and 111.4-5908 (32bit) from nightly server works fine.

So the next nightly the windows GDI Version:
are compiled with MULTI_THREADS=1
and the Version is not striped ....

You can test it with http://www.wernieman.de/sim-2012-09-09.exe (http://www.wernieman.de/sim-2012-09-09.exe)

Edit:
Remove the File

Sorry, this still crashes in the same way. (BTW, typo in URL domain)

Thanks for the Info ... I change the typo ...

Wich Versions of this Libarys do you use?
libunicows.a
libbz2.a
libz.a
zlib.h
zconf.h
bzlib.h

(You fixed the text, but not the link itself.)

I use bzip2 1.0.6-4 and libz 1.2.7-1. I don't link against unicows as I haven't used Win95/98/ME for a long, long time. Strangely, your executable doesn't depend on unicows.dll. I got the impression that it relied on some dynamic linking magic. Or maybe this is an alternate implementation. In any case, it could be interesting to try without it.

libunicows-1.1.1-mingw32, bzip2-1.0.6, zlib-1.2.7, libpng-1.5.12. Previously zlib-1.2.5 and libpng-1.5.7.

sim2012-09-09.exe gives:

Program received signal SIGSEGV, Segmentation fault.
0x007df003 in ?? ()
(gdb) bt
#0  0x007df003 in ?? ()
#1  0x77b59ef2 in ntdll!RtlpNtSetValueKey ()
   from C:\Windows\system32\ntdll.dll
#2  0x7efde000 in ?? ()
#3  0x77b59ec5 in ntdll!RtlpNtSetValueKey ()
   from C:\Windows\system32\ntdll.dll
#4  0x004012c0 in ?? ()
#5  0x00000000 in ?? ()


O.K. Please test a dynamic linked Libary ... http://www.wernieman.de/sim-2012-09-09-2.exe (http://www.wernieman.de/sim-2012-09-09-2.exe)

Edit:
Remove the File

Still crashes. Not much difference in the .exe between -2 and the original, sure it dynamic linked? Which .dlls should it be looking for? Running it in a directory without any dlls it behaves the same - instant crash, no complaint about missing dlls...

I tried singlestepping my way through the CRT startup code, but got lost in something called dyn_tls_init which is called early in mingw_CRTStartup. It appears the crash is somewhere in dyn_tls_init, as the crash occurs before I can reach any breakpoints beyond it.

I make a litte update. Can somebody check?
http://www.wernieman.de/sim-2012-09-10.exe.zip (http://www.wernieman.de/sim-2012-09-10.exe.zip)

Edit:
Delete the File from the Server .. so Link is dead

Still crashes.

Shid ... did somebody have an Idea, to solve it?

at example an older gcc?

I have tested the last build with depwalker and I'm convinced it's not a missing DLL. All LoadLibrary and GetProcAddress calls seem to be successful. Here are the last few lines of log...


DllMain(0x76D60000, DLL_PROCESS_ATTACH, 0x0028FD24) in "WS2_32.DLL" called by thread 1.
DllMain(0x76D60000, DLL_PROCESS_ATTACH, 0x0028FD24) in "WS2_32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x72970000, DLL_PROCESS_ATTACH, 0x0028FD24) in "WSOCK32.DLL" called by thread 1.
DllMain(0x72970000, DLL_PROCESS_ATTACH, 0x0028FD24) in "WSOCK32.DLL" returned 1 (0x1) by thread 1.
First chance exception 0xC0000096 (Privileged Instruction) occurred in "SIM-2012-09-10.EXE" at address 0x007E202C by thread 1.
Second chance exception 0xC0000096 (Privileged Instruction) occurred in "SIM-2012-09-10.EXE" at address 0x007E202C by thread 1.
Exited "SIM-2012-09-10.EXE" (process 0x20B0) with code -1073741674 (0xC0000096) by thread 1.

"Second chance exception" means that it was left unhandled and propagated "upwards".

---

The only thing I could find on this was the last post of some thread somewhere (http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=891#p3257). The solution seems a bit fishy, just changing linker options... Maybe worth a try anyway ;)

Quote
The problem was actually happening when the "References" project option (in Linker\Optimization") was set to "Eliminate Unreferenced Data" which is the case by defaut in release mode; changing it to "Default" resolved the problem for me.

Thanks for the search and the link

But ... they could not linking. This is not the Problem (here). And I don´t see another usefull linking-option

I must steal my Wife her Windows-PC to see the Problem ...

I've noticed that even though we both supposedly use mingwrt-3.20, the machine code in __dyn_tls_init is slightly different between the nightly and mine. And as far as I can tell, the machine code from the nightly enters a loop without realizing that the stop condition is met initially, and keeps on looping until the loop variable wraps and returns to start. As it's looping over a function pointer array, it will be calling random memory addresses. It looks like this looping code (tlssup.c) has been changed recently, but I haven't figured out which versions of the C code the machine code I see matches yet.

Here's the disassembly of __dyn_tls_init from sim-2012-09-09.exe for the hardcore folks. The arrow is at the start of the loop. It should apparently loop from 0x7dd014 to 0x7dd014.

   0x006186f0 <+0>:     push   %ebx
   0x006186f1 <+1>:     sub    $0x18,%esp
   0x006186f4 <+4>:     cmpl   $0x2,0x7d87d0
   0x006186fb <+11>:    mov    0x24(%esp),%eax
   0x006186ff <+15>:    je     0x61870b <__dyn_tls_init@12+27>
   0x00618701 <+17>:    movl   $0x2,0x7d87d0
   0x0061870b <+27>:    cmp    $0x2,%eax
   0x0061870e <+30>:    je     0x618720 <__dyn_tls_init@12+48>
   0x00618710 <+32>:    dec    %eax
   0x00618711 <+33>:    je     0x618744 <__dyn_tls_init@12+84>
   0x00618713 <+35>:    add    $0x18,%esp
   0x00618716 <+38>:    mov    $0x1,%eax
   0x0061871b <+43>:    pop    %ebx
   0x0061871c <+44>:    ret    $0xc
   0x0061871f <+47>:    nop
=> 0x00618720 <+48>:    mov    $0x7dd014,%ebx
   0x00618725 <+53>:    mov    (%ebx),%eax
   0x00618727 <+55>:    test   %eax,%eax
   0x00618729 <+57>:    je     0x61872d <__dyn_tls_init@12+61>
   0x0061872b <+59>:    call   *%eax
   0x0061872d <+61>:    add    $0x4,%ebx
   0x00618730 <+64>:    cmp    $0x7dd014,%ebx
   0x00618736 <+70>:    jne    0x618725 <__dyn_tls_init@12+53>
   0x00618738 <+72>:    add    $0x18,%esp
   0x0061873b <+75>:    mov    $0x1,%eax
   0x00618740 <+80>:    pop    %ebx
   0x00618741 <+81>:    ret    $0xc
   0x00618744 <+84>:    mov    0x28(%esp),%eax
   0x00618748 <+88>:    movl   $0x1,0x4(%esp)
   0x00618750 <+96>:    mov    %eax,0x8(%esp)
   0x00618754 <+100>:   mov    0x20(%esp),%eax
   0x00618758 <+104>:   mov    %eax,(%esp)
   0x0061875b <+107>:   call   0x618dd0 <__mingw_TLScallback>
   0x00618760 <+112>:   jmp    0x618713 <__dyn_tls_init@12+35>
   0x00618762 <+114>:   lea    0x0(%esi,%eiz,1),%esi
   0x00618769 <+121>:   lea    0x0(%edi,%eiz,1),%edi


EDIT:
By using the debugger to jump over the loop, Simutrans managed to open its window, then it crashed like before. Possibly because something calls __dyn_tls_init again.

So it is a Code Problem? Or an compiler Problem?

I could make old Simutransversion too, so we can look, in witch Simutrans-Version come the Problem. At now, in the Time the Code and the Server are changed ....
(Do I write readable english?)

P.S.
@Ters
Witch mingw32 do you use? On Linux or on Windows

If it's a compiler, it's not your compiler, unless you compiled mingwrt from source yourself. I'm getting quite certain the error is in mingwrt.

I use mingw32 on windows. I've got it on a linux box too, but I failed to cross compile bzip2 with it and is therefore unable to proceed to cross compiling Simutrans. However, I could perhaps try to upgrade mingwrt from 3.18 to 3.20 (which I have on my Windows machine) on it and try to build a hello world program. As far as I can tell, every single program made with your setup should fail.

"As far as I can tell, every single program made with your setup should fail."

Can you Explain?

I think Ters says that:
The bug is in code that comes with compiler, so all programs compiled with it should crash.

So I should use an older Compiler?

But ... on linux-32Bit we use the same Version and the it works.

Third appearance of http://sourceforge.net/tracker/?func=detail&aid=3446009&group_id=2435&atid=302435 or what? It might help to turn off or reduce optimization.

werner:

Well, but not the same code, because it is for linux, not windows... ?

You could try some "hello world" compiled with this. If it crashes silently too, then it's clear :)

The code that appears faulty, as far as I can tell, lies in the low level startup code that gets called before main() (or WinMain(), or DllMain()) in order to set up a C/C++ runtime environment. This code is provided by mingw. At least some version of it is at http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/?cvsroot=src (http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/?cvsroot=src). Source tars are also available at mingw's sourceforge home.

I know some Linux distros tend to apply their own set of patches to official releases before passing them on. If you got your mingw packages that way, there may be some unfortunate patch applied that neither of us others have, or their compiler made bad machine code if it's a binary package. My cross compiler was able to make a working hello world program using mingwrt-3.20. It doesn't apply any custom patches.

EDIT: After getting some info about wernieman's system, I think whoami is on it. The mingwrt on my Linux box was compiled with gcc 4.5, while wernieman's appears to have been compiled with gcc 4.6.

O.K. I make a new Cross-Compiler with gcc 4.5.4

Edit:
Next nighty will be no new Windows-Version, because the cross-compiler is not ready

Edit2:
windows-nightlys enabled

I tried the opposite and upgraded the gcc used for mingw cross compiling on my Linux machine to 4.6.2, compiled mingw-rt 3.20 with it, then compiled a simple hello world program using those two (the rest was left as it was). The resulting Window program crashes when I try to run it on my Window machine.

To check further, I compiled the runtime using gcc 4.5.4, but compiled the test program using 4.6.2. That program works.

The problem seems to be that the Linux distro wernieman (and coincidentaly also I) use hasn't picked up the release of mingw-rt 3.20-2, but likes to be bleeding edge for gcc for cross compilers. Wernieman's work-around should work.

Could somebody test the "new" nightly?
http://www.wernieman.de/sim-2012-09-11.exe.zip (http://www.wernieman.de/sim-2012-09-11.exe.zip)
The File is 33MBtye "big", because the debug-Symboles ar not striped

It is compiled with gcc 4.5.4

Seems to work.  :)

You can probably drop the debug symbols again. If one person can get it to work, everybody should.

I do it ... but I wait for a second O.K. bevor I "close the Ticket"

I cannot run it, but this is on W2K. Hiding the DLLs did not help.
DEBUG_EVENT:
dwDebugEventCode = EXCEPTION_DEBUG_EVENT
dwProcessId = 4CC
dwThreadId = 324
ExceptionCode = C000001D
ExceptionFlags = 0
ExceptionAddress = 63BC94
dwFirstChance = 0
sim-2012-09-11. caused an Illegal Instruction at location 0063bc94 in module sim-2012-09-11.exe.

Registers:
eax=00000000 ebx=007de060 ecx=fffffbcb edx=00000000 esi=0022e71c edi=00000040
eip=0063bc94 esp=0022e630 ebp=00000001 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000282

Call stack:
AddrPC     AddrReturn AddrFrame  AddrStack  Params
0063BC94   00000000   00000001   0022E630   00000000   00000000   00000000   00000000
0063BC94  sim-2012-09-11.exe:0063BC94sim-2012-09-11.exe: No symbol found
  BZ2_bzerror

Looks like the new nightly targets a too new CPU. The instruction at 0063bc94 is fisttpl, which give lots of hits with illegal instruction when googled.

Edit:
To clarify a bit: whoami's CPU might technically support the instruction, but Windows 2000 might be to old to activate that support. While I haven't checked if this applies to this instruction, support for some newer CPU functionality must be activated by the OS so that the CPU knows the OS has set aside enough room for the extra data when doing task switching.

Works for me. Win7. :)

Thirded. New build is working.

re: fisttpl - SSE3 instruction added to 'prescott' pentium4 in 2004 - truly ancient CPU. Win2K also ancient - knows nothing of SSE3 or SSE2...

Perhaps time for a legacy build branch of simutrans? The makefile for MinGW targets plain 'pentium' by default, and for Linux leaves it to the default - possibly'i386'; Really ties the compiler optimizers hands. Changing that to 'pentium4' and bringing MMX, SSE, SSE2 et al. into the picture results in a significant speed improvement. And still be fine with 12 year old processors! (P4 from 2000)

O.K. ... the "new" mingw-cross-compiler use for -march the local CPU ... and it is a 2 Years old AMD ...

I try with the next nightly the pentium3 .... or did somebody don´t like it?

I have a computer they a have hypertreading logo.

(Compilation target discussion has been split off: Changing to new CPU compiler setting (http://forum.simutrans.com/index.php?topic=10485.msg100070))

r5914 downloaded today doesn't work. Winzip reports: 'Warning: skipping "sim-wingdi.exe", The 32-bit CRC stored in the local header for this is not the same as the 32-bit CRC stored in the central header. None of the nightlys after r5898 work.

I guess the zip program was upgraded along with the compiler, but does it really produce incorrect zip-files or is WinZip faulty? I thought my zip-program wouldn't go beyond the standard, but it had no problems with at least one post r5898 nightly zip.

The zip-Program is not updated


I test to unzip the aktual Zip-Files (Linux and Win) and can unzip. Do you hafe Problems with the download?

Unpacking and checking sim-wingdi_2012-09-13_v111.4_r5914.zip and sim-winsdl.zip (also r5914) with 7zip shows no errors. (I guess that Winzip cannot handle the .7z files that I normally download.)
Colin: maybe your downloads are truncated (incomplete download) or there is a data corruption, which can have different reasons (wrong file type assumed, software error (e.g. virus scanner), hardware error (often RAM)). Or the problem is (again?) that you download the files when they are created/uploaded in the (European) night.

It seems that you may be right about Winzip although it has always worked before. I downloaded the nightly using WINRAR and it works ok. I've got to re-install Zz I lost when I upgraded to WIN7 Ultimate.

No Probles at the Moment?

So I can "close the call"?

You can as far as I'm concerned, Thanks.

... solved? No. I have to play still with number 5898 - because newer versions don't run - on Win XP.

Quote from: VaclavMacurek on September 17, 2012, 04:04:37 PM
... solved? No. I have to play still with number 5898 - because newer versions don't run - on Win XP.

Any error messages?

Which CPU?

I found a web page stating that Windows XP doesn't support SSE3, but that was mainly focusing on the CPU capabilities as reported by the OS. There is no way, as far as I can see in the x86/x64 manual, that an OS can report to the CPU the exact SSE level it supports, nor any differences between SSE, SSE2 and SSE3 as far as an OS is concerned. An OS should either enable/support SSE in full, or no SSE at all. I'm pretty sure I could use SSE on Windows XP.

So the CPU seems to be the only limiting factor since the time of Windows 98.

prissi: AMD Duron, 1,3 GHz
Ters: common fail message - but DrMinGW says:


sim-winsdl.exe caused an Illegal Instruction at location 0044b89b in module sim-winsdl.exe.

Registers:
eax=00027100 ebx=0025237e ecx=00000000 edx=00000000 esi=00000001 edi=00320031
eip=0044b89b esp=0023edb0 ebp=0023ede8 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

Call stack:
0044B89B  sim-winsdl.exe:0044B89B
00440F4D  sim-winsdl.exe:00440F4D
005A5525  sim-winsdl.exe:005A5525
005B0AA7  sim-winsdl.exe:005B0AA7
0061C2AC  sim-winsdl.exe:0061C2AC
0061D337  sim-winsdl.exe:0061D337
004010BB  sim-winsdl.exe:004010BB
004012C8  sim-winsdl.exe:004012C8
7C816D4F  kernel32.dll:7C816D4F  RegisterWaitForInputIdle


About Windows 98: I used this OS until Christmas of 2009 - but no longer. But it was good OS.

shid ... I don't know the Problem ....

AMD Duron is SSE only, and for the oldest ones not even that. It appears to be contemporary to Pentium III. Looks like we have to extend the processor support further back in time.

Since the Debug build are anyway slow, maybe again set march to pentium II, or even pentium again?

I switch pack to PentiumIII

PentiumII is not testet and today, I have no time ;o)

EDIT:
... did somebody know, how to deaktivate SSE?

I know how to aktivate (-msse), but to deaktivate ....

EDIT2:
O.K. "-mno-sse(2,3) is the solution ...

Next Version will compiled with this Options

Edit3:
for the Devs, this is the config for WinGDI:BACKEND = gdi
COLOUR_DEPTH = 16
OSTYPE = mingw
DEBUG = 3 
OPTIMISE = 1
WITH_REVISION = 1
FLAGS = -DSTEPS16
CCFLAGS = -march=pentium3 -mno-sse -mno-sse2 -mno-sse3
CXXFLAGS = -march=pentium3 -mno-sse -mno-sse2 -mno-sse3
LDFLAGS = -static

CC=mingw32-gcc
CXX=mingw32-c++
LD=mingw32-ld
AR=mingw32-ar
AS=mingw32-as
NM=mingw32-nm
STRIP=mingw32-strip
RANLIB=mingw32-ranlib
DLLTOOL=mingw32-dlltool
OBJDUMP=mingw32-objdump
RESCOMP=mingw32-windres
WINDRES=mingw32-windres

That will sacrifice a lot of functionality. Once back at Pentium, I'm not sure there is anything new and useful in the instruction set since the 386. I wonder how far back gcc 4.5+ can target.
-mno-sse should disable SSE. -mfpmath appear to only be necessary on x64, but if that was targetted, we'd have other problems.

See my last Edit ... I edit it, when you write ...

I would assume that -march=pentium3 or -mno-sse would disable sse2 and sse3 automatically, but better safe than sorry now that you've added them.

This is the Reason, I use it ;o)

better use 2 Flags, than to forget some ...
(Besser zufiel als zuwenig verwenden ... vor allem da Zufiel nicht schadet)

Edit:
I see, that the last wingdi was build with penium3 ....... and he has a Problem with it ...

Maybe he doesn't have the very latest. I can't get hold of the nightly download page either, so I haven't been able to check which instruction it might be choking on.

And by the way, the STEP16 flag is gone, or so I have been told.

It is not "in use" or "it is bad to set it"?

It will be wonderfull, when a Dev could look to the config ...

Last compiletime:
Windows/GDI Version: 111.4-5929
Date: Sep 17 2012  at 04:31  (MEZ)

Wehn profiling with DEBUG on (which is hopefully on with the nightly) the only difference in speed was between pentium and pentium2 (which were both supported with GCC 4.6.2). There have been few new command with the pentium, like the conditions move.

O.K., so at the Moment the config is

BACKEND = gdi
COLOUR_DEPTH = 16
OSTYPE = mingw
DEBUG = 3
OPTIMISE = 1
WITH_REVISION = 1
FLAGS = -DSTEPS16

CCFLAGS = -march=pentium2 -mno-sse -mno-sse2 -mno-sse3
CXXFLAGS = -march=pentium2 -mno-sse -mno-sse2 -mno-sse3
LDFLAGS = -static

CC=mingw32-gcc
CXX=mingw32-c++
LD=mingw32-ld
AR=mingw32-ar
AS=mingw32-as
NM=mingw32-nm
STRIP=mingw32-strip
RANLIB=mingw32-ranlib
DLLTOOL=mingw32-dlltool
OBJDUMP=mingw32-objdump
RESCOMP=mingw32-windres
WINDRES=mingw32-windres


The last nightly (18.09) was build with pentium3

I think there is no need to say no-sse when you target pentium2, as SSE is from later generations.

Test of latest nightly was not succesful.

And here is message from DrMinGW:

sim-wingdi.exe caused an Illegal Instruction at location 00640d14 in module sim-wingdi.exe.

Registers:
eax=00000000 ebx=007e3040 ecx=fffffbcb edx=00000000 esi=0023e70c edi=00000040
eip=00640d14 esp=0023e620 ebp=00000001 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000282

Call stack:
00640D14  sim-wingdi.exe:00640D14  BZ2_bzerror


WinXP or a new System?

Win XP.

Since bz2 might be also self compiled, maybe there was still the pentium4 setting?

no, bz2 is from "the old" mingw32 ...

Set target to 386. That's as low as Simutrans can possibly go on the PC platform. If that doesn't work, the problem lies elsewhere.

EDIT:
What did you target when building the mingw runtime? Has that been downgraded too?

I look at my mingw32 ... but sorry, today I do nothing ... enough Serverproblems (at Work) ;o)

I think the mingw runtime should be compiled with a very low CPU target. Perhaps not as low as 386, but since it's not project specific, it should target a low common denominater. Hopefully, there isn't much performance critical stuff in it. There's also other compiler specific libraries (like libstdc++ and libgcc). I'm not sure how to tune them.

pentium should be ok. i386 will not run any existing OS (ok Windows 95 original was the last that could have run on that target). But any after Windows95 and up uses a pentium (while technically it was still possible to run windows 98 on a 486, windows ME was not longer supporting then 486).

I whave a (little) Idea, how to solve it .... but I need Time for it

I did actually have to provide support for a user using Windows 98 this year. It almost made me fall off the chair, but it shows that there is some old stuff out there. The hardware was probably just as old. Fortunately for the user, the program I've become the (sole) support contact for was made for Windows 95 and feels more at home on Windows 98 than Windows 7. A Mac user wasn't so lucky.

The 386 suggestion was perhaps a bit exaggerated, but it would rule out the compilation of Simutrans itself yielding any illegal instructions, unless there was a compiler bug.

Sorry, but there are the official simutrans too. I think User with this Hardware did not use the newest nigthly ...

I just checked and the fisttp instruction is still in sim-wingdi_2012-09-19_v111.4_r5932.zip. (Curiously, fisttp seems to be an SSE3 feature, but is a normal FPU instruction, not an SSE instruction. It should still come and go with -m(no)-sse3, as the debate on whether to add a separate -mno-fisttp to gcc seems to have ended with "no".)

Test of 5935 was not successful

message given by Dr. MinGW:

sim-winsdl.exe caused an Illegal Instruction at location 00640724 in module sim-winsdl.exe.

Registers:
eax=00000000 ebx=007e3080 ecx=fffffbcb edx=00000000 esi=0023e83c edi=00000040
eip=00640724 esp=0023e750 ebp=00000001 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200282

Call stack:
00640724  sim-winsdl.exe:00640724  BZ2_bzerror


... I think that it is the same.

yes, it is the same, because I have no time to make the new new mingw32 ........

I hope, that at weekend I could build it. I need some hours ...

Some hours?

With 5959 it still does not run. Error log keeps the same. It is attached.

I don't know, how to solve it ... I make a verry new mingw32-cross-compiler and it did not work ....

I must try to get a Windows-PC, so it is easyer for me to make bug-Hunting ....

(is "easyer" correct english??)

Quote from: wernieman on October 01, 2012, 06:50:00 PM
(is "easyer" correct english??)

No, it is not correct. Easier is correct. When short word ends with y, then y change into i.
Easy - easier, lazy - lazier ...  :)

And to all other matter of message, thanks for info.  :-[

Does the build in http://simutrans-germany.com/files/upload/simgdi_r5961.zip (http://simutrans-germany.com/files/upload/simgdi_r5961.zip) work? (On Win95/98 it probably won't.)

No.

Error log is attached.
There is nothing about BZ2 ... but it is all I can read from it.

Just a suggestion - I compile my test releases in wine (actually in mingw in wine). It's a bit of a roundabout way of doing things but it avoids cross compiling (and also means the executable can be tested).

I have a Windows machine and it runs there, so Wine doesn't help much with testing. The main problems seem to be to convince gcc to target an old enough CPU. I would need a virtual machine and a copy of Windows XP for that. Or I need to find a way to grep an executable for specific instructions.

It is possible that the pre-compiled mingw for Windows is configured to target old enough architectures, but mine is also set up to link dynamically (or worse, half dynamically and half statically), so one also needs a bunch of DLLs. It also gives a big load of ugly warnings during linking.

EDIT:
I found a way to grep an executable (though in the end, I didn't use grep). The fisttp instructions seemed to originate from the mingw-runtime, which for some reasons get compiled using host settings rather than target settings (if I got my cross compilation nomenclature right). After googling a way to override host settings for that particular package (I can't downgrade my entire system to pentium2), I got an executable with no signs of fisttp. I've updated http://simutrans-germany.com/files/upload/simgdi_r5961.zip (http://simutrans-germany.com/files/upload/simgdi_r5961.zip) with this fix. If it works, wernieman can try to do the same to his setup.

When you can give me a "white Paper", I could try it .... and I test with my PC, because it is quicker than the Server

Quote from: Ters on October 02, 2012, 04:41:07 AM
EDIT:
I found a way to grep an executable (though in the end, I didn't use grep). The fisttp instructions seemed to originate from the mingw-runtime, which for some reasons get compiled using host settings rather than target settings (if I got my cross compilation nomenclature right). After googling a way to override host settings for that particular package (I can't downgrade my entire system to pentium2), I got an executable with no signs of fisttp. I've updated http://simutrans-germany.com/files/upload/simgdi_r5961.zip (http://simutrans-germany.com/files/upload/simgdi_r5961.zip) with this fix. If it works, wernieman can try to do the same to his setup.

This version of 5961 runs - at first glance. Game started right. I shall see what I shall see later - if there is something wrong.

In case anyone is wondering, I sent wernieman my recipe for apparent success a few days ago. It's not exactly trivial, so I don't know how long it will take to put into effect (or even if it has been already).

Thanks to Ters for the Info ... but the last Day I was not at Home (Holliday :o) )

Today I make the mingw32 with the Info from Ters ... so we could loog for the next Version. But only GDI! The SDL is at the moment an old Version auf the mingw32 Cross-Compiler

Some days passed ... and still no new nightly works. So I have to use nightly by Ters.

That's not really a nightly, just a random snapshot. And one that by now is older than the latest stable release.

I downloaded latest available nightly - 6006 and there game crashes with the same log as in the beginning - bz_.... but I did not know about stable release. So I am going to test it ... and I shall see what I shall see.

WinSDL or WinGDI?

At the moment it i a different compilation!

Both fail to start.

shid .... I don´t know to solve it :o(

And how Ters solved it? That at least GDI was running (aside of minor problems of type that my monitor resize screen in wrong way* - but it is not something that is on side of game).

With SDL is no problem - but with GDI monitor resizes screen. And in own screen of monitor (Philips, 192E) is not visible all what should be visible. Mostly it is clear on status line - because coords or icon for time axis are not fully visible ... mostly after shutting down of game screen (with windows key or so). But as I wrote, it is not on side of game.

GDI switches the monitor to 16 bit only when using full screen. If the graphics card then changes its timing, then this is a bug in the driver of the graphics card. (Since 16 bit modes are not used much any more, those are often not really tested.)

Either use SDL or not the fullscreen mode and just maximize the window.

So ... at the moment ... did it work?

I could not test :o(

It still does not run - 6029. I try (almost) all versions (as they appear on nightlies pages) - and as I tested number 6000 from nightlies pages, it does not run - while number 6000 published in stable ...

It is strange.

Is there a different between GDI and SDL?

No. There is not any difference.

... but they are different Compiler :o(

May it be ... it is all that is clear to me. I don't comprehend it.

Can VaclavMacurek report the address it crashes on this time, for both GDI and SDL? And can wernieman provide unstripped executables? I've disassembled both the SDL and the GDI executable, and the SDL version has fewer fisttp instructions than the GDI version, though both still have a few. I don't think I actually checked the entire files before. The ones both have are all localized in a small section of code, so it's probably just one source left.

You only need the unstriped exe?

Then I make a spezial Compiler run on next Weekend.

Quote from: wernieman on November 08, 2012, 08:15:00 PM
You only need the unstriped exe?

I think that should do. (No -s when linking.)

Debug logs in attachment.

I make a spezial run
http://www.wernieman.de/6041.zip (http://www.wernieman.de/6041.zip)

But ... it is the Version r6041 .. and in th zip-File are the both unstriped exe

Tested ... and result is in attachment.

It's exactly the same code in both, in the function __gdtoa. __gdtoa is part of the mingw-runtime, so unless there is another implementation of it coming in from some other source, mingw-runtime still isn't built with the correct target.

correct target? what target do you speak about? this is something where I am lost.

target = processor family / type. The post is directed at wernieman ;)

Mhhh ..... In the last year Gentoo change the crossdev-skript ... :o(

At the Moment the make show:

CHOST=i686-pc-mingw32
CBUILD=x86_64-pc-linux-gnu
ARCH=x86

HOSTCC=x86_64-pc-linux-gnu-gcc
E_MACHINE=EM_386

ROOT=/usr/${CHOST}/

#ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_KEYWORDS="x86"

USE="${ARCH} zlib bindist make-symlinks minimal"

#MARCH_TUNE="-march=armv4t -mtune=arm9tdmi"     #arm-softfloat-linux-uclibc
#MARCH_TUNE="-march=armv5t -mtune=xscale"       #armv5teb-softfloat-linux-gnueabi

#CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer"
CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"


As I told you before in a private message, mingw-runtime is for some reason not compiled with the crossdev settings, but with your host settings. It's a bug in my opinion, and the workaround is to the set package specific settings in package.env.

Soo ...... I make a new try ... please check: http://www.wernieman.de/6043.zip (http://www.wernieman.de/6043.zip)

Quote from: wernieman on November 12, 2012, 03:07:23 PM
Soo ...... I make a new try ... please check: http://www.wernieman.de/6043.zip (http://www.wernieman.de/6043.zip)

I still find the same fisstpl instructions.

EDIT:
It would perhaps be less time consuming if you ran i686-pc-mingw32-objdump -d sim.exe | grep fisttp yourself. If you get more or less than 8 hits, something has changed, for better or worse.

I make at know different Versions ... but I get the same Problem :o (

Thanks for the Tip with
i686-pc-mingw32-objdump -d sim.exe | grep fisttp

Edit:
Tommorow a make a new try with some Information I get from some friends ..

O.K. next try: http://www.wernieman.de/6045.zip (http://www.wernieman.de/6045.zip)

Please test (I hope it works ....)

And you hope right. This runs right.

Did somebody else can give me Information?

Or is the Bug solved (at the Moment)?

I am in the process of setting up mingw. If I run the grep command like Ters suggested, it is showing these fisttp instructions. These instructions are in sections named .gcc_except_table. (~ 12 hits)

Are these instructions executed at all ? Or is this just data lying in a table?

My last Version i testet have no hits.

The Problem:
I compile on an Gentoo.System and there the mingw use the wrong make.conf

50% offtopic: With the next upcoming processor of intel with 64 hyperthreading pentium cores, there might again arise the need for pure pentium settings at least for servers ...

Other than that, the may issue seems to be solved? (Unsure where to put this thread for now.)

Quote from: Dwachs on November 21, 2012, 07:46:27 PM
I am in the process of setting up mingw. If I run the grep command like Ters suggested, it is showing these fisttp instructions. These instructions are in sections named .gcc_except_table. (~ 12 hits)

Are these instructions executed at all ? Or is this just data lying in a table?

If you have proper symbols throughout the rest of the disassembly, it might be that it has disassembled data, but I don't think it should with my command. It is also possible that you have built an executable targetting a newer architecture (not specifying one might pick the host architecture, or the default is Pentium 3 now).

If there are almost no symbols, then you need to stop removing them.