2 Problems

[Dummie]

Hey,

I got two very annoying problems

I installed SFML 1.3 and all is working fine. I turned "Release-Mode" on and when the application start the program crashs. But if I use SFML 1.2 all works fine. But of course, I would prefer to use SFML 1.3.

I tried to link statically to the CRT(Multi-Threaded) so I don't have to provide the .NET-Framework and so on. Unfortunately it doesn't work. I get tons of linking errors. I used SFML 1.2 because SFML 1.3 doesn't work for me in release mode. Is SFML not compatible to it?

In all cases I used the static version of SFML.

Some solutions?

Thanks,
Dummie

[Laurent]

Hi

I turned "Release-Mode" on and when the application start the program crashs

Do you link to the release libraries (without the "-d" suffix) in release mode ?

I tried to link statically to the CRT(Multi-Threaded) so I don't have to provide the .NET-Framework and so on

It's not a solution, a program and all its linked libraries must use the same version of the CRT. Anyway, you don't have to provide the .Net framework, only the few VC++ DLLs (search vcredist_x86 on MSDN).

[dabo]

I tried to link statically to the CRT(Multi-Threaded) so I don't have to provide the .NET-Framework and so on. Unfortunately it doesn't work. I get tons of linking errors. I used SFML 1.2 because SFML 1.3 doesn't work for me in release mode. Is SFML not compatible to it?

I rebuilded the static libraries with the correct settings (Multi-Threaded) and it works great.

[Dummie]

I turned "Release-Mode" on and when the application start the program crashs

Do you link to the release libraries (without the "-d" suffix) in release mode ?

I'm linking to: sfml-system-s.lib sfml-window-s.lib sfml-graphics-s.lib

It still doesn't work

[lohr]

Hm Why sou are link to the ending "-s" ?
Try it normal with "SFML-...lib" without ending "-*"

[eleinvisible]

"-s" endings are for static. Just check and make sure under project settings you have disabled debug information from being included

[Dummie]

Hey,

my settings are working fine with SFML 1.2. Why they dont work with SFML 1.3? I created a project and tried it in debug mode. All worked perfect. I turned the release mode on. Compiling all is fine...

I start my application and it crashs. Could you tell me which settings I should check? I'm using Visual Studio 2008 Express.

Edit:

If I try to link without -s I get linker errors. Like this:

Main.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: static class sf::IPAddress const sf::IPAddress::LocalHost" (?LocalHost@IPAddress@sf@@2V12@B)".

This error doesnt appear if I link to the -s librarys. But the program crashs when I run it.

[Mindiell]

Maybe you can zip your project, letting someone using VC2008 try your project ?

[Dummie]

I think something is wrong with my computer. I also can't run the sample executables   I will reinstall it soon and I hope all will work again fine then.

[T.T.H.]

Same with me:

The following, minimalistic program...

Code: [Select]

#include "SFML/Graphics.hpp"
#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "started" << std::endl;
  sf::RenderWindow MyRenderWindow(sf::VideoMode(640, 480), "SFML", sf::Style::Close);
  std::cout << "stopped" << std::endl;
  return 0;
}
...does run in Debug mode but does crash in Release mode.

My own exception handling code in my "big" application tells me it's a so called "win32 hardware exception" of the type EXCEPTION_ILLEGAL_INSTRUCTION.

Libraries used in Debug mode: sfml-system-s-d.lib sfml-window-s-d.lib sfml-graphics-s-d.lib

Libraries used in Release mode: sfml-system-s.lib sfml-window-s.lib sfml-graphics-s.lib

Windows 2000 SP 4 with AMD Athlon XP 2000+ (1.7 GHz) on some ASUS mainboard with onboard soundcard but without joystick :roll:

Visual C++ 2005 Express Edition with Windows Platform SDK Windows Server 2003 R2

SFML revision 743 (updated today, 3. July 2008)

SFML revision 651 (which I used till today) did work fine so far

[Laurent]

Which version of the CRT are you linking in release mode ?

[T.T.H.]

As I said I have "Microsoft Platform SDK for Windows Server 2003 R2" installed. That even includes the tool Dependancy Walker ("Depends.exe") which tells me my application ("TestSFMLMinimalistic.exe") depends on the following libraries: screenshot (sorry, is a screenshot - anybody knows how to export from that tool?)

When I check the versions of the files "msvcrt.dll", "msvcr80.dll" and "msvcrp80.dll" in the directory "C:\WINNT\system32" their versions are the same as in the screenshot. The only other files with the same names are located in "E:\Winapp32\Microsoft Platform SDK for Windows Server 2003 R2\Bin\win64" and "E:\Winapp32\Microsoft Platform SDK for Windows Server 2003 R2\Bin\win64\x86" but it seems they are for 64 bit Windows only.

When I extract the manifest (with the tool "mt.exe") from my application ("TestSFMLMinimalistic.exe") I get the following manifest:

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Hope that helps...  

[Dummie]

When the window that reports me about the crash appear and I press "Debug" I see the problem has something to do with:

Code: [Select]

__tmainCRTStartup()

Any solutions?

[T.T.H.]

Using r758 after a full rebuild still results in the same crash even in my minimalistic application.

Anybody has a clue what to do from here on?

Unfortunately this puts me on "full stop" regarding SFML and it seems I have to use SFML 1.2.x till this problem is solved.

[T.T.H.]

Bumping a old topic because I still have the described problem and I finally had some time for more investigation.

Note: opengl = the opengl sample of SMFL.

My test:
1. svn update to a certain revision
2. "Rebuild opengl" in "Release static" mode; this actually rebuilds sfml-system, sfml-window, sfml-graphics, sfml-main and said opengl sample
3. start opengl
4. see whether it crashes of not

All revisions I tried up to 651 do work. All revisions I tried from 652 upwards (652, 675, 700, 774, 900) crash. The log message of revision 652 is:

Removed sf::OpenGLCaps class
Removed exportation of GLEW functions

By using the function _set_se_translator plus a selfwritten "translator" function (which translates from win32 hardware exceptions into std::exceptions) I found out a so called EXCEPTION_ILLEGAL_INSTRUCTION occurs.

Intermission: to use the _set_se_translator you need the following compiler settings:

Project Properties -> C/C++ -> Code Generation -> Enable C++ Exceptions = Yes With SEH Exceptions (/EHa)

More details about all that topic can be found here.

By adding a lot more std::cerr and try/catch blocks I tried to locate the position of the problem. Unfortunately I was not able to find something "interesting" but still I am posting here in the hope that it helps other to keep searching. My "best" find is the info that something goes wrong in the constructor of WindowImpl while initializing the joysticks. Some debug output gibberish:

Code: [Select]

create main window...
WindowSettings::WindowSettings
VideoMode::VideoMode with parameters
WindowSettings::WindowSettings
Window::Window with parameters
RenderWindow::RenderWindow with parameters [1]
VideoMode::VideoMode copy constructor
Window::Create [1]
Window::ForceContextInit
WindowImpl::New
 - Win32 window
JoystickState::JoystickState (08865010)
JoystickState::JoystickState (08865040)
WindowImpl::WindowImpl
Joystick::UpdateState
 - State...
JoystickState::JoystickState (0012CB2C)
 - Caps...
 - joyGetDevCaps...
 - return...
JoystickState::operator= (08865010 = 0012CB2C)
JoystickState::~JoystickState (0012CB2C)
$ catched in WindowImpl::WindowImpl
JoystickState::~JoystickState (08865040)
JoystickState::~JoystickState (08865010)
$ catched in static WindowImpl::New
=== ERROR ===
std::exception occurred:
Create failed, reason:
ForceContextInit failed, reason:
sf::priv::WindowImpl::New failed, reason:
new WindowImplWin32 failed, reason:
myJoyStates[i] = myJoysticks[i].UpdateState() failed (i = 0), reason:
win32 exception occurred, reason:
illegal instruction

As you can see I added a constructor, copy constructor, destructor and assignment operator to JoystickState, including some std::cerr output (the 8 digit numbers are memory address, simply outputing *this).

For some wicked the reason the assignment operator in the constructor of WindowImpl seems to fail:

Code: [Select]

myJoyStates[i] = myJoystick[i].UpdateState();
The UpdateState(i) works but then the assignment fails - or something like that. Guesstimationtheory: myJoyStates is not "there", meaning the assignment operator dumps data somewhere into memory where it assumes myJoyStates to be but where it is not or is not anymore. Guesstimationtheoryreason: stack/heap corruption (partly based on what I describe below now).

Then I say "ooookay, who needs joysticks anyway, let's drop the whole crap!" and so I added the following:

Code: [Select]

WindowImpl::WindowImpl() :
myWidth       (0),
myHeight      (0),
myJoyThreshold(0.1f)
{
  std::cerr << "WindowImpl::WindowImpl" << std::endl;

  // ### TEST ###
  std::cerr << " - INSTARETURN" << std::endl;
  return;

...which results in the following debug output gibberish...

Code: [Select]

create main window...
WindowSettings::WindowSettings
VideoMode::VideoMode with parameters
WindowSettings::WindowSettings
Window::Window with parameters
RenderWindow::RenderWindow with parameters [1]
VideoMode::VideoMode copy constructor
Window::Create [1]
Window::ForceContextInit
WindowImpl::New
 - Win32 window
JoystickState::JoystickState (08865010)
JoystickState::JoystickState (08865040)
WindowImpl::WindowImpl
 - INSTARETURN
WindowImplWin32::WindowImplWin32
 - Create a dummy window
 - Create the rendering context
WindowSettings::WindowSettings
VideoMode::VideoMode with parameters
WindowImplWin32::CreateContext
 - A
 - B
 - C
 - C1
 - C1a
$ catched in WindowImplWin32::WindowImplWin32
WindowImpl::~WindowImpl
JoystickState::~JoystickState (08865040)
JoystickState::~JoystickState (08865010)
$ catched in static WindowImpl::New
=== ERROR ===
std::exception occurred:
Create failed, reason:
ForceContextInit failed, reason:
sf::priv::WindowImpl::New failed, reason:
new WindowImplWin32 failed, reason:
CreateContext failed, reason:
win32 exception occurred, reason:
illegal instruction

The relevant code is in src\SFML\Window\Win32\WindowImplWin32.cpp:

Code: [Select]

       // Setup a pixel format descriptor from the rendering settings
        PIXELFORMATDESCRIPTOR PixelDescriptor;
        std::cerr << " - C1a" << std::endl;
        ZeroMemory(&PixelDescriptor, sizeof(PIXELFORMATDESCRIPTOR));
        std::cerr << " - C1b" << std::endl;

Oha. Zeromemorying a local variable does not work?!? Well, screw MS functions, us the good ol' memset:

Code: [Select]

memset(&PixelDescriptor, 0, sizeof(PIXELFORMATDESCRIPTOR));
Same result, bamm!

So while I have no clue whether the local variable PixelDescriptor is in memory or not or wherever it might be, at least my compiler does consider it a problem to zeromemory it.

That combined with the "illegal instruction" wickedness makes me think "stack/heap" corruption because that is a decent cause to name when things go "really, really wrong beyond logical reasons".

Anyway, back to a bit more rational viewpoint: something on the way from ...

Code: [Select]

sf::RenderWindow App(sf::VideoMode(800, 600), "SFML OpenGL");
...in the main function towards the initialization of joysticks within the construction of WindowImpl (which happens during the construction of one of its derivative classes) "something" goes wrong. And probably leaves the stack/heap in a mess. Which causes a "illegal instruction" win32 exception. During the initialization of joysticks or during zeromemorying local variables.

Unfortunately this all only happens in Release mode, not in Debug mode. Probably because Debug mode a) always zeromemories all memory and variables and b) it allocates some "memory guards" around some memory pieces to detect memory corruption but which in my case does not detect it but actually hides it due to some important code parts being not overwritten due to the additional "memory guards" around something.

My best hope would be to be able to set a breakpoint even in Release mode and having a call stack with fully readable function names available at that breakpoint. I would need to know the relevant compiler settings for that. Without making any other changes so it doesn't get "Another Debug" mode where the problem does not happen anymore.

My next best hope would be that somebody reads all this thoughts and miraculously finds the missing puzzle piece. Actually it must be somewhere in revision 652 or is at least directly caused by the changes in revision 652 because that's the point where it starts to crash.

Over and out,
T.T.H.
*actuallyquitefrustrated*