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 4631 - [LINUX] Error to execute 32bit SDL2 to 64bit OS
Summary: [LINUX] Error to execute 32bit SDL2 to 64bit OS
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: 2.0.9
Hardware: x86_64 Linux
: P2 critical
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-17 09:47 UTC by cictec
Modified: 2020-03-24 20:20 UTC (History)
0 users

See Also:


Attachments
SDL assert error (9.54 KB, image/png)
2020-01-03 21:23 UTC, cictec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cictec 2019-05-17 09:47:12 UTC
Hello,

I'm using Ubuntu 16.04 LTS 64bit for developments.

I downloaded the source of the latest version of SDL2 2.0.9 and compiled the 64bit version and the 32bit version.

The 32bit version was compiled in the following way using the configure script for SDL:
./configure --build=i686-pc-linux-gnu "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 make

Both libraries have been compiled well and both seem to have all the necessary dependencies installed in the system, here the reports:
64bit version:
ldd libSDL2-2.0.so.0.9.0

linux-vdso.so.1 => (0x00007ffeebebe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff49f9a1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff49f79d000)
libsndio.so.6.1 => /usr/lib/x86_64-linux-gnu/libsndio.so.6.1 (0x00007ff49f58d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff49f370000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff49f168000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff49ed9e000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff4a0011000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007ff49ea9e000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007ff49e889000)

32bit version:
ldd libSDL2-2.0.so.0.9.0

linux-gate.so.1 => (0xf777b000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7592000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf758d000)
libsndio.so.6.1 => /usr/lib/i386-linux-gnu/libsndio.so.6.1 (0xf757b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf755e000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7554000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf739e000)
/lib/ld-linux.so.2 (0xf777c000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xf7288000)
libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf726c000)

He used the same test program...

The 64bit version works without issues.

The 32bit version launches the following error message:
WARN:

Assertion failure at SDL_SetWindowSize_REAL (../SDL/x86/SDL2-2.0.9/src/video/SDL_video.c:1985), triggered 1 time:
  'window && window-> magic == & _this-> window_magic'

Both in the shell and as a messagebox with a series of options, it is impossible to ignore or continue, the only option eg Abort to interrupt the execution.

Could it be a bug in SDL2 or is it missing some dependencies to install in Linux?


Regards.
Comment 1 cictec 2020-01-03 21:23:21 UTC
Created attachment 4148 [details]
SDL assert error
Comment 2 cictec 2020-01-03 21:23:54 UTC
Hello,

I recently recompiled the new 32 and 64 bit SDL2 2.0.10 in the operating system in use (Ubuntu 16.04 LTS 64bit).

The 64bit version works correctly.
The 32bit version continues to display an assert messagebox as in the attached screenshot, however pressing "Ignore" or "Always Ignore", the application starts and execution continues without problems.

I believe it may be an SDL2 bug at this point, I hope it can be identified and corrected soon.

Regards.
Comment 3 Sam Lantinga 2020-01-03 22:26:05 UTC
Can you debug the 32-bit version and see why that assert is failing? It shouldn't fail, and I can't think of any reason why 32 vs 64-bit would matter here.
Comment 4 cictec 2020-01-04 00:11:00 UTC
Hello Sam Latinga,

Ok, I did some debugging

I have the following code:
hWndProg = 0;

SDL_SetMainReady();
if(SDL_Init(0) != 0) {
	printf((char *)SDL_GetError());
	return 0;
}

SDL_SetWindowSize(hWndProg, wnd_w, wnd_h);

hWndProg = SDL_CreateWindow((char *)program_name,
                            SDL_WINDOWPOS_CENTERED,
                            SDL_WINDOWPOS_CENTERED,
                            wnd_w,
                            wnd_h,
                            SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);
if(hWndProg == NULL) {
	printf((char *)SDL_GetError());
	return 0;
}


The problem is in the call to SDL_SetWindowSize, changing the code like this:
SDL_SetWindowSize(SDL_Window * window, int w, int h)
{
printf("window: %d (%X), window->magic: %d (%X), _this->window_magic: %d (%X)\n",
       (int)window, window, window ? window->magic : 0, window ? window->magic : 0, (int)&_this->window_magic, &_this->window_magic);
    CHECK_WINDOW_MAGIC(window,);
...


The output of the 32bit version is this:
window: 0 (0), window->magic: 0 (0), _this->window_magic: 151521132 (908076C)
WARN: 

Assertion failure at SDL_SetWindowSize_REAL (/home/.../Desktop/Development_Libraries/SDL/linux/x86/SDL2-2.0.10/src/video/SDL_video.c:1990), triggered 1 time:
  'window && window->magic == &_this->window_magic'

window: 152763656 (91AFD08), window->magic: 151521132 (908076C), _this->window_magic: 151521132 (908076C)
window: 152763656 (91AFD08), window->magic: 151521132 (908076C), _this->window_magic: 151521132 (908076C)


The output of the 64bit version is this:
window: 0 (0), window->magic: 0 (0), _this->window_magic: 10796720 (A4BEB0)
window: 10975632 (A77990), window->magic: 10796720 (A4BEB0), _this->window_magic: 10796720 (A4BEB0)
window: 10975632 (A77990), window->magic: 10796720 (A4BEB0), _this->window_magic: 10796720 (A4BEB0)


The function SDL_SetWindowSize is called 3 times, the first time is before the creation of the window, and of course it fails, but the problem does not seem to be in the 32bit version, but in the 64bit version since the assert fails to be executed.

I don't know the cause why assert fails in the 64bit version, I just compiled the library in the following way:
- 32bit:
./configure --build=i686-pc-linux-gnu CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
make

- 64bit:
./configure
make

I hope the information is useful to correct any bugs.

Regards.
Comment 5 Ryan C. Gordon 2020-01-04 00:52:49 UTC
(In reply to cictec from comment #4)
> I don't know the cause why assert fails in the 64bit version, I just
> compiled the library in the following way:

We turn off assertions by default if optimizations are enabled in the build, and the configure script by default will turn _on_ optimizations.

My guess is that building it with CFLAGS set for the 32-bit build overrides this, so you get no optimizations when building the library. Try this instead:

./configure --build=i686-pc-linux-gnu CFLAGS="-m32 -O3" CXXFLAGS=-m32 LDFLAGS=-m32

(added "-O3" to the CFLAGS)

--ryan.
Comment 6 cictec 2020-01-04 01:33:23 UTC
Hi Ryan C. Gordon,

Your guess is correct, adding -O3 the assert is not launched, I have corrected the program for SetWindowSize to be called later, thanks for the support.

As a suggestion, it would be interesting to add options to cmake and make in order to generate 32bit and 64bit builds, it is very common and convenient especially in Linux to be able to build for multiple architectures and test them. For CMAKE you could indicate an option like: cmake -DSDL_BUILD_CPUARCH=32 .., this would allow you to create a 32bit build, if the value was 64 it would be created at 64bit, if you do not specify the option it would create the default SO (32 or 64bit that is), a similar option also for configure (make).

Regards.
Comment 7 Ryan C. Gordon 2020-03-24 20:20:37 UTC
Resolving this bug since the mystery was solved.

I _think_ CMake can build for other CPU architectures with some magic incantation, like the configure's --build param, but I don't know it off the top of my head. I don't _think_ it needs any changes to SDL to do it, but I could be wrong.

--ryan.