Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endless loop in SDL_InitDynamicAPI #3399

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Endless loop in SDL_InitDynamicAPI #3399

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2019-09-14 01:09:48 +0000, Rudolf Polzer wrote:

When using SDL_DYNAMIC_API=SDL_DYNAMIC_API=/usr/lib/x86_64-linux-gnu/libSDL2.so ./someprogram, where libSDL2.so is 2.0.10 and ./someprogram is statically linked against 2.0.9, the program loops endlessly in SDL_Init.

I already went through gdb with this, and found the root cause:

On 2019-09-14 01:11:34 +0000, Rudolf Polzer wrote:

As a suggested fix, I propose changing

286 if (!entry) {
287 if (!initialize_jumptable(SDL_DYNAPI_VERSION, &jump_table, sizeof (jump_table))) {
288 /* !!! FIXME: now we're screwed. Should definitely abort now. */
289 }
290 }

to simply

286 if (!initialize_jumptable(SDL_DYNAPI_VERSION, &jump_table, sizeof (jump_table))) {
287 /* !!! FIXME: now we're screwed. Should definitely abort now. */
288 }

Also, at least some error messages would really do this function good...

On 2019-09-14 18:14:42 +0000, Ryan C. Gordon wrote:

(In reply to Rudolf Polzer from comment # 0)

libSDL2.so is 2.0.10 and ./someprogram is statically linked against 2.0.9,
[...]

But the loaded library should be 2.0.10, the statically-linked version is 2.0.9, and it should have a tablesize that's less than sizeof (jump_table) at this point.

(Unless I'm misreading this code and missing the bug) we had to be in the wrong entry point here (2.0.10 library calling into static 2.0.9's SDL_DYNAPI_entry.

I'll try to reproduce here.

--ryan.

On 2019-09-14 22:24:48 +0000, Rudolf Polzer wrote:

Sorry, I made a mistake in the OP.

In my concrete scenario, the statically linked version was 2.0.10 and the .so was 2.0.9.

This is not supposed to work, but it should not loop endlessly either. Desired result is either an error or a warning being printed, and the program either continuing or exiting, but not looping endlessly.

On 2019-09-15 02:55:57 +0000, Ryan C. Gordon wrote:

(In reply to Rudolf Polzer from comment # 3)

This is not supposed to work, but it should not loop endlessly either.

Oh, I see. Yes, that sounds like a bug.

--ryan.

On 2019-09-20 20:47:38 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:41 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-10-14 16:42:04 +0000, Ryan C. Gordon wrote:

This should be fixed with https://hg.libsdl.org/SDL/rev/eaac8e676d45 !

--ryan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant