News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

r5899 nightly fails to start

Started by The Hood, August 31, 2012, 08:19:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

The Hood

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.

DirrrtyDirk

  
***** PAK128 Dev Team - semi-retired*****

Ters

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.

DirrrtyDirk

#3
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...
  
***** PAK128 Dev Team - semi-retired*****

prissi

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

TurfIt

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.

DirrrtyDirk

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.
  
***** PAK128 Dev Team - semi-retired*****

prissi

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

whoami

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.)

Ters

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

wernieman

#10
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
Is Windows-GDI in a new mingw32
I hope you understand my English

whoami

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.

wernieman

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??
I hope you understand my English

whoami

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.

wernieman

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 ....
I hope you understand my English

whoami

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.

Ters

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.

wernieman

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 hope you understand my English

Ters

#18
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.

whoami

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 and 2) 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.)

prissi

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.

Ters

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.

TurfIt

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?

Vonjo

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

wernieman

#24
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

Edit:
Remove the File
I hope you understand my English

whoami

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

wernieman

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


I hope you understand my English

Ters

(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.

TurfIt

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 ?? ()


wernieman

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

Edit:
Remove the File
I hope you understand my English

TurfIt

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...

Ters

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.

wernieman

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

Edit:
Delete the File from the Server .. so Link is dead
I hope you understand my English

TurfIt


wernieman

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

at example an older gcc?
I hope you understand my English