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.

VS

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

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wernieman

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

Ters

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

wernieman

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

Ters

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.

wernieman

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

Can you Explain?
I hope you understand my English

VS

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

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wernieman

So I should use an older Compiler?

But ... on linux-32Bit we use the same Version and the it works.
I hope you understand my English

whoami


VS

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

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Ters

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

wernieman

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

Ters

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.

wernieman

Could somebody test the "new" nightly?
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
I hope you understand my English

DirrrtyDirk

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

Ters

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

wernieman

I do it ... but I wait for a second O.K. bevor I "close the Ticket"
I hope you understand my English

whoami

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


Ters

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

Vonjo


TurfIt

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)

wernieman

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

greenling

I have a computer they a have hypertreading logo.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

whoami


Colin

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 may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

Ters

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.

wernieman

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

whoami

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.

Colin

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.
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

wernieman

No Probles at the Moment?

So I can "close the call"?
I hope you understand my English

Colin

You can as far as I'm concerned, Thanks.
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

Václav

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

Chybami se člověk učí - ale někteří lidé jsou nepoučitelní

Ters

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?

prissi


Ters

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.