We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3617 - SDL 2.05 fails timer init
Summary: SDL 2.05 fails timer init
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: timer (show other bugs)
Version: 2.0.5
Hardware: x86_64 Windows 7
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-26 23:27 UTC by mattreecebentley
Modified: 2018-08-07 02:20 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mattreecebentley 2017-03-26 23:27:29 UTC
mingwx64 6.3 or 5.1
win7 x64
8gb ram
core2duo e8500
nvidia gtx 750
latest mainstream drivers as of 23/3/2017

sdl2.05: under the above system, 2.05 fails on SDL_INIT_TIMER. Bug not present in 2.04 and will run fine.
Comment 1 mattreecebentley 2017-03-26 23:30:23 UTC
ps. Also could not run on MSVC2015.
Comment 2 Ryan C. Gordon 2017-03-27 05:39:43 UTC
Can you call SDL_GetError() right after this fails and tell us what it reports?

Thanks,
--ryan.
Comment 3 mattreecebentley 2017-03-27 07:29:56 UTC
Freezes when it fails, so no opportunity to log error. Minimal test case is as follows - works on v2.04, not v2.05, at least on my machine:
#include <fstream> // log redirection
#include <iostream>

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>


int main( int argc, char* args[] )
{
	freopen("plf.log","w",stderr); //redirect std::clog and std::cerr to file

	// Initialise SDL graphics and subsystems:
	if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_EVENTS|SDL_INIT_TIMER) < 0)
	{
		std::clog << "SDL_Error: " << SDL_GetError();
	}

	std::cin.get();

	return 0;
}

IDE is codelite, if that makes any difference.
Comment 4 Ryan C. Gordon 2017-03-27 14:22:04 UTC
(In reply to mattreecebentley from comment #3)
> Freezes when it fails, so no opportunity to log error. Minimal test case is

It freezes somewhere under SDL_Init()?! Is it possible for you to break in a debugger and see where it got hung up?

I'll try to reproduce here, too.

--ryan.
Comment 5 mattreecebentley 2017-03-27 21:23:20 UTC
Unfortunately it won't give me any info!
current call stack location just resolves to a random memory address. Could be  somewhere in the dll code rather than the user code. Unsure.
Comment 6 mattreecebentley 2017-03-27 22:04:45 UTC
ps. obviously the #include <SDL2/SDL_image.h> line is not needed. Oversight on my part.
Comment 7 mattreecebentley 2017-03-27 22:08:08 UTC
If you're trying to reproduce, here are the two mingw vers I've been using:
https://nuwen.net/mingw.html (6.3 x64)
http://tdm-gcc.tdragon.net/download (5.1 x64)
Comment 8 mattreecebentley 2017-05-20 01:29:16 UTC
Can confirm that executables built with 2.05 will run fine from command prompt or windows explorer - they just won't run within the codelite or MSVC IDE's. So, something to do with debug hooking?
No idea.
Comment 9 Ryan C. Gordon 2017-06-06 05:11:23 UTC
This is turning out to be a pretty mysterious bug.

--ryan.
Comment 10 mattreecebentley 2017-06-06 05:54:42 UTC
Can confirm the MSVC2015 executables also run from the command line fine (but not from within IDE). Glad to hear it's being investigated :-)
Comment 11 mattreecebentley 2017-08-13 23:28:04 UTC
Hi there-
just tried building under Codelite 10.7, mingw x64 v7.1 (nuwen builds) and it all worked fine with sdl 2.05.

I've also tested under VCC and found that the crash occurring there was purely to do with the working directory being set incorrectly.

I've re-tested with codelite mingw x64 6.3 (nuwen) and mingw x64 5.1 (TDM) and both still fail.

So, the problem only occurs with those two GCC builds.
Whether it occurs with earlier build versions I don't know.
Thanks,
Matt
Comment 12 Ryan C. Gordon 2018-08-06 21:20:19 UTC
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.
Comment 13 mattreecebentley 2018-08-06 23:55:23 UTC
Appears to work in 2.08
Comment 14 Ryan C. Gordon 2018-08-07 02:20:59 UTC
Yay!  :)

--ryan.