SFML community forums

Help => General => Topic started by: Dummie on June 30, 2008, 10:47:28 am

Title: 2 Problems
Post by: Dummie on June 30, 2008, 10:47:28 am
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
Title: 2 Problems
Post by: Laurent on June 30, 2008, 11:14:30 am
Hi

Quote
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 ?

Quote
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).
Title: Re: 2 Problems
Post by: dabo on June 30, 2008, 12:03:06 pm
Quote from: "Dummie"
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.
Title: 2 Problems
Post by: Dummie on June 30, 2008, 01:56:43 pm
Quote from: "Laurent"

Quote
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 :(
Title: 2 Problems
Post by: lohr on July 01, 2008, 11:54:40 am
Hm Why sou are link to the ending "-s" ?
Try it normal with "SFML-...lib" without ending "-*"
Title: 2 Problems
Post by: eleinvisible on July 01, 2008, 11:10:04 pm
"-s" endings are for static. Just check and make sure under project settings you have disabled debug information from being included
Title: 2 Problems
Post by: Dummie on July 02, 2008, 02:46:08 pm
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:

Quote
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.
Title: 2 Problems
Post by: Mindiell on July 02, 2008, 02:52:16 pm
Maybe you can zip your project, letting someone using VC2008 try your project ?
Title: 2 Problems
Post by: Dummie on July 02, 2008, 03:05:14 pm
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.
Title: 2 Problems
Post by: T.T.H. on July 03, 2008, 12:16:13 am
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
Title: 2 Problems
Post by: Laurent on July 03, 2008, 02:48:03 am
Which version of the CRT are you linking in release mode ?
Title: 2 Problems
Post by: T.T.H. on July 03, 2008, 06:25:00 pm
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 (http://www.teeteehaa.de/SFML/dependencies_2008_07_03.png) (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...  :(
Title: 2 Problems
Post by: Dummie on July 05, 2008, 08:09:36 pm
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?
Title: 2 Problems
Post by: T.T.H. on July 07, 2008, 08:48:19 pm
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.
Title: 2 Problems
Post by: T.T.H. on October 09, 2008, 11:59:14 pm
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:
Quote from: "Log"
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:
Quote
Project Properties -> C/C++ -> Code Generation -> Enable C++ Exceptions = Yes With SEH Exceptions (/EHa)

More details about all that topic can be found here (http://www.thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/).

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*
Title: 2 Problems
Post by: SirJulio on October 10, 2008, 12:56:00 am
Wow ! Thanks for all your investigations.

I thinks that we have a similar issue here (http://www.sfml-dev.org/forum/viewtopic.php?t=676) (crash only in release, on RenderWindow instanciation).

I see if i can find something with all your infos (but RenderWindow never crashed on my computer =( ).
Title: 2 Problems
Post by: T.T.H. on October 10, 2008, 09:45:34 am
In this (http://www.sfml-dev.org/forum/viewtopic.php?p=4413#4413) post fixus971 mentions he's using Windows 2000, too, just like me. In another (http://www.sfml-dev.org/forum/viewtopic.php?p=4440#4440) post he says "I tested on WinXP SP2 with framework 2 just installed" - the question is: did he compile it on Windows 2000 and then did run it on Windows XP or did he both compile and run it on Windows XP? So maybe it all is a problem only when compiling on Windows 2000.

Update: I found a nice article (http://www.codeproject.com/KB/debug/survivereleasever.aspx) about the differences between Debug and Release builds and how to find bugs in the later one.
Title: 2 Problems
Post by: T.T.H. on October 15, 2008, 10:23:48 am
Short update:

Yesterday I tried r908 (HEAD) of SFML because the changes in r901 sounded promising ("Fixed global graphics context sometimes initialized after global drawable objects") but "opengl.exe" still crashed in release mode.

In addition I tried switching off all the optimization in release mode (changed "/Ox" into "/Od") but that didn't help either.
Title: 2 Problems
Post by: T.T.H. on October 15, 2008, 08:12:52 pm
Another update:

disclaimer

I am using VC++ 2005 under Windows 2000 with a ATI Radeon 9800 Pro.


how to make it crash
[list=1]
Title: 2 Problems
Post by: Laurent on October 15, 2008, 08:29:46 pm
Hmm, why r652? It's so old...
Title: 2 Problems
Post by: T.T.H. on October 15, 2008, 08:31:56 pm
Quote from: "Laurent"
Hmm, why r652? It's so old...

That's why:
Quote from: "T.T.H."
All revisions I tried up to 651 do work. All revisions I tried from 652 upwards (652, 675, 700, 774, 900) crash.

I'm trying to find the minimum amount of changes which lead to the crash - and they seem to be somewhere in revision 652.


If I try the very same on revision 980 instead of revision 658 then it crashes again (D'OH) but now it's in "atioglxx.dll" whereas the last functions before a long list of "atioglxx.dll" errors are "opengl.exe!sf::Image::CreateTexture()" and "opengl.exe!sf::Image::LoadFromFile()".

So currently I personally assume there are two different problems: the "inlining away" thing and the "atioglxx.dll" thing.
Title: 2 Problems
Post by: Beaker on October 16, 2008, 07:32:19 am
I was having lots of crashes with atioglxx.dll until I upgraded my graphics drivers. Have you tried that?
Title: 2 Problems
Post by: T.T.H. on October 16, 2008, 10:21:14 am
Quote from: "Beaker"
I was having lots of crashes with atioglxx.dll until I upgraded my graphics drivers. Have you tried that?

No. And I do not intend to.

I do have ATI Radeon 9800 Pro from Sapphire with 128 MB Ram on 400 Mhz running with a ATI Catalyst 4.4 driver version 6.14.0010.6436 on Windows 2000 SP 4. Obviously the Catalyst is pretty old (April 2004) but pretty stable so far (regarding games like Warcraft 3 and Guild Wars). First I strongly believe in "never change a running system" and second at some point next year I will buy a new PC anyway and till that I don't intend to "misconfigure" my current PC with driver installations.

As I said I believe there are two problems: so far I am stuck at the first one (bad inlining) and the second one (atioglxx.dll) is of no big relevance for me - at least not yet.

P.S.@Beaker: which driver version did you have before and which driver version do you have now?
Title: 2 Problems
Post by: zarka on October 16, 2008, 10:51:01 am
Quote from: "T.T.H."
First I strongly believe in "never change a running system"


well.. it obviously doesn't run stable anymore does it ;) well all jokes aside .. updating graphics drivers is a pretty safe thing to do. (i have never ever encountered errors in updating graphics drivers (though quite a few errors have been solved when doing this)) and The game you named Warcraft 3 and Guild Wars are quite old :) but then again since sfml is a 2d api one would expect it to run well on old hardware...
Title: 2 Problems
Post by: T.T.H. on October 16, 2008, 11:10:48 am
Quote from: "zarka"
well.. it obviously doesn't run stable anymore does it

It does run Warcraft 3, Guild Wars and SFML r651.

Quote from: "zarka"
updating graphics drivers is a pretty safe thing to do. (i have never ever encountered errors in updating graphics drivers (though quite a few errors have been solved when doing this))

I've been through a lot of pain myself regarding drivers and driver installations and I have witnessed scary stories of friends about updating drivers so I have absolutely zero zip zilch interest in touching them again.

On the other hand... I want SFML to work... *sigh*

Quote from: "zarka"
but then again since sfml is a 2d api one would expect it to run well on old hardware...

Yup, I'd hope so. And repeating myself (I must start sounding like a broken record) r651 works. So at some point something in SFML changed which causes a crash in "atioglxx.dll". I know it's not the fault of SFML because no OpenGL driver should ever crash but nevertheless there must be some relevant change in SFML. Maybe eventually it might be interesting to find out what that change is.


Anyway, back to optimistic ideas: some people in the official Neverwinter Nights forum (which is quite an old game, too, and which does use OpenGL, too) they say that at some point the "atioglxx.dll" of the Catalyst became "bugged" (something around Catalyst 4.3 or 4.4) and it helps to get the "atioglxx.dll" from Catalyst 4.2 (only that file, not the whole driver!) and put that file in the application directory. This looks like a nice try since it doesn't mess around with driver installations but only some file copying and so I might try that one out.

Funnily enough in the official AMD/ATI forums there is some similar suggestion with more modern games: "atioglxx.dll" from Catalyst 8.8 or 8.9 does crash while from Catalyst 8.7 or lower it does not crash.


But now for something completely different: does anybody of you intelligent guys have any idea what gets ""inlined away"" (in r652...) and why it gets ""inlined away"" and how I do proceed in debugging it?!?
Title: 2 Problems
Post by: Beaker on October 16, 2008, 11:59:40 am
Quote
P.S.@Beaker: which driver version did you have before and which driver version do you have now?


Can't remember what I was on, but now I'm on 8.530.0.0 for Win XP. For 2000 though there is 6.2. Although if everything else runs fine, I agree, don't fix what's not broken.
Title: 2 Problems
Post by: T.T.H. on October 16, 2008, 09:56:37 pm
Today I tried r910 in
- "Debug static"
- "Release static" with optimization and inlining turned off

with "atioglxx.dll"
- version 6.14.10.5646 from Catalyst 6.2 (extracted and put next to "opengl.exe")
- version 6.14.10.4273 from Catalyst 4.4 (my original graphics driver)
- version 6.14.10.4145 from Catalyst 4.2 (extracted and put next to "opengl.exe")
- version 6.14.10.4103 from Catalyst 4.1 (extracted and put next to "opengl.exe")

but it all crashes  :evil: (always somewhere in "atioglxx.dll")


Callstack in "Debug static"
(http://www.teeteehaa.de/SFML/callstack_opengl_debug.png)

Callstack in "Release static"
(http://www.teeteehaa.de/SFML/callstack_opengl_release.png)


Function in "Image::CreateTexture()" that seems to work:
Code: [Select]
GLCheck(glBindTexture(GL_TEXTURE_2D, Texture));


Function in "Image::CreateTexture()" that seems to work not:
Code: [Select]
GLCheck(glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, myTextureWidth, myTextureHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, GetPixelsPtr()));
whereas "GetPixelsPtr()" returns not NULL but the casted array.




Back to the think tank...
Title: 2 Problems
Post by: T.T.H. on October 16, 2008, 10:45:15 pm
Think tank broke:

atioglxx.dll version 6.14.10.8086 from Catalyst 8.10 (from 15. Oct. 2008, so it's still hot!) simply exists(-1) during function
Code: [Select]
BestFormat = ChoosePixelFormat(myDeviceContext, &PixelDescriptor);
in function
Code: [Select]
void WindowImplWin32::CreateContext(const VideoMode& Mode, WindowSettings& Params)
but Catalyst 8.10 is waaaay newer than my graphics card, my graphics card driver or my operation system  (Catalyst 8.10 is made for WinXP, not Win2000) so I consider this neither a problem nor a solution (and I should try to stop cheating my operation system, me evul person).

:roll:
Title: 2 Problems
Post by: T.T.H. on November 25, 2008, 10:34:36 pm
Good news:

Today I tried r927 of SFML, which includes the bugfix of Laurent (r924+) based on the error description of wizardofoz (http://www.sfml-dev.org/forum/viewtopic.php?p=4883#4883), as "Release static" with all optimization enabled (which is the default of SFML) but with all SSE optimizations turned off as described by spackle (http://www.sfml-dev.org/forum/viewtopic.php?t=763) and it did work!!!

It seems my problems with "atioglxx.dll" have been solved by the issue addressed by wizardofoz and it seems my problems which I described as "inlined away" had been solved by the issue addressed by spackle.

@ Laurent: could you please have a look at spackle's findings regarding SSE and adjust the compile settings of SFML accordingly?

For info: I do have an "AMD Athlon XP 2000+" which actually runs at 1.7 GHz (which is the default, not overclocked) and has a "Palomino core" according to CPUID.

P.S.:  :D  :D  :D  :D  :D  :D  :D  :D  :D  :D
Title: 2 Problems
Post by: Laurent on November 25, 2008, 10:53:55 pm
Quote
@ Laurent: could you please have a look at spackle's findings regarding SSE and adjust the compile settings of SFML accordingly?

Done ;)