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 4803

Summary: Endless loop in SDL_InitDynamicAPI
Product: SDL Reporter: Rudolf Polzer <divVerent>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: sezeroz
Version: HG 2.0Keywords: target-2.0.12
Hardware: All   
OS: All   

Description Rudolf Polzer 2019-09-14 01:09:48 UTC 
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:

- SDL_Init calls jump_table.SDL_Init: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l160 

- jump_table.SDL_Init is actually SDL_Init_DEFAULT at startup: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l135

- SDL_Init_DEFAULT calls SDL_InitDynamicAPI then jump_table.SDL_Init: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l143

- SDL_InitDynamicAPI calls SDL_InitDynamicAPILocked: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l321

- SDL_InitDynamicAPILocked detects that the environment variable is set, resolves SDL_DYNAPI_entry, and calls into the specified library to fill the jump table: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l282

- The loaded library (2.0.9) refuses to fill in a 2.0.10 jump table because a new call got added: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l182

- Because however SDL_DYNAPI_entry existed, the program never calls initialize_jumptable: https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l286

- Therefore, SDL_InitDynamicAPI does precisely nothing.

- Therefore, SDL_Init_DEFAULT's call to jump_table.SDL_Init resolves to SDL_Init_DEFAULT.

- ENDLESS TAIL RECURSION! Program hangs.
Comment 1 Rudolf Polzer 2019-09-14 01:11:34 UTC 
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...
Comment 2 Ryan C. Gordon 2019-09-14 18:14:42 UTC 
(In reply to Rudolf Polzer from comment #0)
> libSDL2.so is 2.0.10 and ./someprogram is statically linked against 2.0.9,
> [...]
> - The loaded library (2.0.9) refuses to fill in a 2.0.10 jump table because
> a new call got added:
> https://hg.libsdl.org/SDL/file/2ede888544ac/src/dynapi/SDL_dynapi.c#l182

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.
Comment 3 Rudolf Polzer 2019-09-14 22:24:48 UTC 
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.
Comment 4 Ryan C. Gordon 2019-09-15 02:55:57 UTC 
(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.
Comment 5 Ryan C. Gordon 2019-09-20 20:47:38 UTC 
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.
Comment 6 Ryan C. Gordon 2019-09-20 20:48:41 UTC 
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.
Comment 7 Ryan C. Gordon 2019-10-14 16:42:04 UTC 
This should be fixed with https://hg.libsdl.org/SDL/rev/eaac8e676d45 !

--ryan.