At wits end: libSDL for Ubuntu/segfault on SDL_Flip

Trevor_Bradley · April 27, 2009, 3:11am

Hey everyone… I’m at my wits end here, so I thought I’d post here and
see if anyone could help.

I’m developing a game using SDL. I was developing on Slackware Linux
using home-compiled SDL 1.2.13 with no problems for a good 2 months.
Recently I’ve changed my operating system to Ubuntu, and that’s when the
problems for my app began.

Using Ubuntu’s SDL libs (also 1.2.13) and I got this very strange
problem when attempting to blit surfaces with alpha channels:

http://www.randomlynx.net/temp/sdl.png

The center window should be shaded grey with an alpha of 127, instead I
get the green stripy effect.

I actually had a copy of libSDL-1.2.so.0 left over from my Slackware
build (1.5MB in size instead of Ubuntu’s 0.5MB), and if I ran my game
against it, there was no visual glitch.

Figuring this might be an Ubuntu lib issue, I decided to give up and
directly compile libSDL on my own… and that’s when things got worse.
My app, now with an LD_LIBRARY_PATH of /usr/local/lib, gave a segfault
every time it ran. GDB reports the following:

trevor at pergamon:~/Projects/GalacticArtifact/trunk$ export
LD_LIBRARY_PATH=/usr/local/lib/
trevor at pergamon:~/Projects/GalacticArtifact/trunk$ gdb ./GalacticArtifact
GNU gdb 6.8-debian
Copyright © 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i486-linux-gnu”…
(gdb) r
Starting program:
/home/trevor/Projects/GalacticArtifact/trunk/GalacticArtifact
[Thread debugging using libthread_db enabled]
[New Thread 0xb7ae36d0 (LWP 28193)]
[New Thread 0xb7ae2b90 (LWP 28196)]
bt
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7ae36d0 (LWP 28193)]
SDL_Flip (screen=0x0) at ./src/video/SDL_video.c:1087
1087 if ( screen == SDL_ShadowSurface ) {
(gdb) bt
#0 SDL_Flip (screen=0x0) at ./src/video/SDL_video.c:1087
#1 0x08096da9 in ScreenSurface::flip ()
#2 0x080b9a1b in startClient ()
#3 0x080bcae2 in main ()

If I set my LD_LIBRARY_PATH back to /usr/lib, the program runs and has
the visual glitches I mentioned before.

Figuring my program was complicating things, I decided that reducing the
program to the smallest size would be the way to go… it turns out
simply invoking SDL_Flip causes the same error! For instance, the
following simple program also generates the same SDL_Video.c error at
line 1087:

#include “SDL/SDL.h”

#define SCREEN_WIDTH 800
#define SCREEN_HEIGHT 600
#define SCREEN_CENTER 300
#define SCREEN_DEPTH 16

int main(int argc, char *argv[]) {
SDL_Surface *screen;
SDL_Event event;

SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_DEPTH,
SDL_SWSURFACE);

SDL_Flip(screen);
}

gdb Backtrace says SDL_Flip is causing the segfault.

I’ve not done anything special installing SDL… your standard

tar zxfv SDL-1.2.13.tar.gz ; ./configure; make; sudo make install

I’m at my wits end here trying to solve this problem… I’d appreciate
any help anyone would be able to give, either on the original alpha
glitch problem, or preferably to this SDL segfault issue.

Thanks in advance!

JonnyD · April 27, 2009, 4:10am

Hey Trevor,

The green stripe glitch looks a lot like an image or color format
problem. It may be that the function you use to draw the gray
rectangle is not properly taking into account the bit depth or packing
order of the color components in the screen (maybe it’s trying to
change the alpha component of the screen, which has none). The
defaults on these things can change between OSes, and apparently
between builds of SDL as you’ve found

Could you post your ‘bad’ .so somewhere? It’d probably be nice to have
some corroboration.

Jonny D

Trevor_Bradley · April 27, 2009, 6:45am

Hey Trevor,

The green stripe glitch looks a lot like an image or color format
problem. It may be that the function you use to draw the gray
rectangle is not properly taking into account the bit depth or packing
order of the color components in the screen (maybe it’s trying to
change the alpha component of the screen, which has none). The
defaults on these things can change between OSes, and apparently
between builds of SDL as you’ve found

Could you post your ‘bad’ .so somewhere? It’d probably be nice to have
some corroboration.

Jonny D
I wish the alpha issue were a coding issue, but the libSDL left over from my old system still works great with the same code.
If I swap between the old libSDL and the Ubuntu libSDL, the problem vanishes and reappears…

I’ve created a tar.gz file with three versions of libSDL-1.2.so.0 I’ve been working with…

/usr/local/lib/libSDL-1.2.so.0.11.2

This is the version that causes segfaults, compiled by hand on my newest Ubuntu system from the tar.gz souces.

/usr/lib/libSDL-1.2.so.0.11.2

This is the version that ships with Ubuntu, in deb package libsdl1.2debian version 1.2.13-4ubuntu3.

/var/shared/GalacticArtifact/libs/Linux/libSDL-1.2.so.0

And this is the version that works great from me, left over from when I compiled by hand on my old Slackware system.

The .tar.gz file can be downloaded from here:

http://www.randomlynx.net/temp/libsdl.tar.gz

Thanks Jonny.

Trevor

JonnyD · April 27, 2009, 3:48pm

The Ubuntu .so works fine for me, but the other two cause segfaults on
a skeletal program. Your debugger output hints that you’re passing
NULL to SDL_Flip(). I just tried this and it does indeed segfault.
For some reason, it seems that SDL_SetVideoMode() is failing. Try
passing 0 for the screen depth:

screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_SWSURFACE);

That way you’ll get the best that the system can give you. I would
guess that it’s just not happy giving you a 16-bit screen surface?

Some other suggestions are to stick with software surfaces
(SDL_SWSURFACE) for anything with an alpha channel or to try using
SDL_DisplayFormatAlpha() where pertinent (This also speeds up the
blitting). Unless there’s a good reason to use intermediate surfaces,
I also suggest that you just draw straight to the screen surface
instead.

I hope that helps!
Jonny DOn Mon, Apr 27, 2009 at 2:45 AM, Trevor Bradley <trevor.bradley at shaw.ca> wrote:

Hey Trevor,

The green stripe glitch looks a lot like an image or color format
problem. ?It may be that the function you use to draw the gray
rectangle is not properly taking into account the bit depth or packing
order of the color components in the screen (maybe it’s trying to
change the alpha component of the screen, which has none). ?The
defaults on these things can change between OSes, and apparently
between builds of SDL as you’ve found

Could you post your ‘bad’ .so somewhere? ?It’d probably be nice to have
some corroboration.

Jonny D

I wish the alpha issue were a coding issue, but the libSDL left over from my
old system still works great with the same code. ?If I swap between the old
libSDL and the Ubuntu libSDL, the problem vanishes and reappears…

I’ve created a tar.gz file with three versions of libSDL-1.2.so.0 I’ve been
working with…

/usr/local/lib/libSDL-1.2.so.0.11.2

This is the version that causes segfaults, compiled by hand on my newest
Ubuntu system from the tar.gz souces.

/usr/lib/libSDL-1.2.so.0.11.2

This is the version that ships with Ubuntu, in deb package libsdl1.2debian
version 1.2.13-4ubuntu3.
/var/shared/GalacticArtifact/libs/Linux/libSDL-1.2.so.0

And this is the version that works great from me, left over from when I
compiled by hand on my old Slackware system.

The .tar.gz file can be downloaded from here:

http://www.randomlynx.net/temp/libsdl.tar.gz

Thanks Jonny.

Trevor

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Trevor_Bradley · April 27, 2009, 4:04pm

Jonathan Dearborn wrote:

The Ubuntu .so works fine for me, but the other two cause segfaults on
a skeletal program. Your debugger output hints that you’re passing
NULL to SDL_Flip(). I just tried this and it does indeed segfault.
For some reason, it seems that SDL_SetVideoMode() is failing. Try
passing 0 for the screen depth:

screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_SWSURFACE);

That way you’ll get the best that the system can give you. I would
guess that it’s just not happy giving you a 16-bit screen surface?

Some other suggestions are to stick with software surfaces
(SDL_SWSURFACE) for anything with an alpha channel or to try using
SDL_DisplayFormatAlpha() where pertinent (This also speeds up the
blitting). Unless there’s a good reason to use intermediate surfaces,
I also suggest that you just draw straight to the screen surface
instead.

I hope that helps!
Jonny D
Hi Jonny. I’ve tried messing about with my skeletal program… Same
error when changing screen depth (16, 24, 32, 0) and surface type
(SDL_SWSURFACE, SDL_HWSURFACE). It looks like my compiled libSDL
returns null for SDL_SetVideoMode() no matter what it’s passed.

This is a fairly fresh intrepid system just upgraded to jaunty… if
this persists I should probably attempt to reproduce on another machine
to see if it’s a machine or OS issue.

There’s got to be something missing from my system that would produce a
broken libSDL library after a source compile. I know it’s a bit long,
but here’s my ./configure output… There’s got to be something in
there that gives a clue: (Though the only thing that looks out of place
is the ESD version)

./configure
checking build system type… i686-pc-linux-gnu
checking host system type… i686-pc-linux-gnu
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking how to run the C preprocessor… gcc -E
checking for grep that handles long lines and -e… /bin/grep
checking for egrep… /bin/grep -E
checking for ANSI C header files… yes
checking for sys/types.h… yes
checking for sys/stat.h… yes
checking for stdlib.h… yes
checking for string.h… yes
checking for memory.h… yes
checking for strings.h… yes
checking for inttypes.h… yes
checking for stdint.h… yes
checking for unistd.h… yes
checking whether byte ordering is bigendian… no
checking for a sed that does not truncate output… /bin/sed
checking for ld used by gcc… /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld… yes
checking for /usr/bin/ld option to reload object files… -r
checking for BSD-compatible nm… /usr/bin/nm -B
checking whether ln -s works… yes
checking how to recognise dependent libraries… pass_all
checking dlfcn.h usability… yes
checking dlfcn.h presence… yes
checking for dlfcn.h… yes
checking for g++… g++
checking whether we are using the GNU C++ compiler… yes
checking whether g++ accepts -g… yes
checking how to run the C++ preprocessor… g++ -E
checking for g77… no
checking for xlf… no
checking for f77… no
checking for frt… no
checking for pgf77… no
checking for cf77… no
checking for fort77… no
checking for fl32… no
checking for af77… no
checking for xlf90… no
checking for f90… no
checking for pgf90… no
checking for pghpf… no
checking for epcf90… no
checking for gfortran… no
checking for g95… no
checking for xlf95… no
checking for f95… no
checking for fort… no
checking for ifort… no
checking for ifc… no
checking for efc… no
checking for pgf95… no
checking for lf95… no
checking for ftn… no
checking whether we are using the GNU Fortran 77 compiler… no
checking whether accepts -g… no
checking the maximum length of command line arguments… 32768
checking command to parse /usr/bin/nm -B output from gcc object… ok
checking for objdir… .libs
checking for ar… ar
checking for ranlib… ranlib
checking for strip… strip
checking if gcc supports -fno-rtti -fno-exceptions… no
checking for gcc option to produce PIC… -fPIC
checking if gcc PIC flag -fPIC works… yes
checking if gcc static flag -static works… yes
checking if gcc supports -c -o file.o… yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries… yes
checking whether -lc should be explicitly linked in… no
checking dynamic linker characteristics… GNU/Linux ld.so
checking how to hardcode library paths into programs… immediate
checking whether stripping libraries is possible… yes
checking if libtool supports shared libraries… yes
checking whether to build shared libraries… yes
checking whether to build static libraries… yes
configure: creating libtool
appending configuration tag “CXX” to libtool
checking for ld used by g++… /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld… yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries… yes
checking for g++ option to produce PIC… -fPIC
checking if g++ PIC flag -fPIC works… yes
checking if g++ static flag -static works… yes
checking if g++ supports -c -o file.o… yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries… yes
checking dynamic linker characteristics… GNU/Linux ld.so
checking how to hardcode library paths into programs… immediate
appending configuration tag “F77” to libtool
checking for gcc… (cached) gcc
checking whether we are using the GNU C compiler… (cached) yes
checking whether gcc accepts -g… (cached) yes
checking for gcc option to accept ISO C89… (cached) none needed
checking whether we are using the GNU C++ compiler… (cached) yes
checking whether g++ accepts -g… (cached) yes
checking for a BSD-compatible install… /usr/bin/install -c
checking whether make sets $(MAKE)… yes
checking for windres… no
checking for linux-gnu-windres… no
checking for an ANSI C-conforming const… yes
checking for inline… inline
checking for working volatile… yes
checking for ANSI C header files… (cached) yes
checking for sys/types.h… (cached) yes
checking stdio.h usability… yes
checking stdio.h presence… yes
checking for stdio.h… yes
checking for stdlib.h… (cached) yes
checking stddef.h usability… yes
checking stddef.h presence… yes
checking for stddef.h… yes
checking stdarg.h usability… yes
checking stdarg.h presence… yes
checking for stdarg.h… yes
checking malloc.h usability… yes
checking malloc.h presence… yes
checking for malloc.h… yes
checking for memory.h… (cached) yes
checking for string.h… (cached) yes
checking for strings.h… (cached) yes
checking for inttypes.h… (cached) yes
checking for stdint.h… (cached) yes
checking ctype.h usability… yes
checking ctype.h presence… yes
checking for ctype.h… yes
checking math.h usability… yes
checking math.h presence… yes
checking for math.h… yes
checking iconv.h usability… yes
checking iconv.h presence… yes
checking for iconv.h… yes
checking signal.h usability… yes
checking signal.h presence… yes
checking for signal.h… yes
checking for size_t… yes
checking for int64_t… yes
checking for working alloca.h… yes
checking for alloca… yes
checking for working memcmp… yes
checking for working strtod… yes
checking for mprotect… yes
checking for malloc… yes
checking for calloc… yes
checking for realloc… yes
checking for free… yes
checking for getenv… yes
checking for putenv… yes
checking for unsetenv… yes
checking for qsort… yes
checking for abs… yes
checking for bcopy… yes
checking for memset… yes
checking for memcpy… yes
checking for memmove… yes
checking for strlen… yes
checking for strlcpy… no
checking for strlcat… no
checking for strdup… yes
checking for _strrev… no
checking for _strupr… no
checking for _strlwr… no
checking for strchr… yes
checking for strrchr… yes
checking for strstr… yes
checking for itoa… no
checking for _ltoa… no
checking for _uitoa… no
checking for _ultoa… no
checking for strtol… yes
checking for strtoul… yes
checking for _i64toa… no
checking for _ui64toa… no
checking for strtoll… yes
checking for strtoull… yes
checking for atoi… yes
checking for atof… yes
checking for strcmp… yes
checking for strncmp… yes
checking for _stricmp… no
checking for strcasecmp… yes
checking for _strnicmp… no
checking for strncasecmp… yes
checking for sscanf… yes
checking for snprintf… yes
checking for vsnprintf… yes
checking for iconv… yes
checking for sigaction… yes
checking for setjmp… yes
checking for nanosleep… yes
checking for libiconv_open in -liconv… no
checking for pow in -lm… yes
checking for GCC -fvisibility=hidden option… yes
checking for dlopen… yes
checking for dlopen in -lc… no
checking for dlopen in -ldl… yes
checking for dlvsym in -ldl… yes
checking for yasm… no
checking to see if supports unquoted-sections… no
checking for nasm… no
checking altivec.h usability… no
checking altivec.h presence… no
checking for altivec.h… no
checking for Altivec with GCC -maltivec option… no
checking for Altivec with GCC -faltivec option… no
checking for OSS audio support… yes
checking for dmedia audio support… no
checking for ALSA CFLAGS…
checking for ALSA LDFLAGS… -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.0… not present.
checking for snd_ctl_open in -lasound… no
checking for artsc-config… no
checking for esd-config… no
checking for ESD - version >= 0.2.8… no
*** The esd-config script installed by ESD could not be found
*** If ESD was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the ESD_CONFIG environment variable to the
*** full path to esd-config.
checking for pkg-config… /usr/bin/pkg-config
checking for PulseAudio 0.9 support… no
checking audio/audiolib.h usability… yes
checking audio/audiolib.h presence… yes
checking for audio/audiolib.h… yes
checking for AuOpenServer in -laudio… no
checking nas/audiolib.h usability… no
checking nas/audiolib.h presence… no
checking for nas/audiolib.h… no
checking for AuOpenServer in -lnas… no
checking for NAS audio support… no
checking for X… no
checking for framebuffer console support… yes
checking for getpagesize… yes
checking for directfb-config… no
checking for pkg-config… (cached) /usr/bin/pkg-config
checking for DirectFB 0.9.15 support… no
checking for PlayStation 2 GS support… no
checking for SVGAlib (1.4.0+) support… no
checking for libVGL support… no
checking for wscons support… no
checking for OpenGL (GLX) support… no
checking for Linux 2.4 unified input interface… yes
checking for Touchscreen library support… no
checking for hid_init in -lusbhid… no
checking usb.h usability… no
checking usb.h presence… no
checking for usb.h… no
checking libusb.h usability… no
checking libusb.h presence… no
checking for libusb.h… no
checking for hid_init in -lusb… no
checking for usbhid… no
checking for pthreads… yes
checking for recursive mutexes… yes
checking for pthread semaphores… yes
checking linux/version.h usability… yes
checking linux/version.h presence… yes
checking for linux/version.h… yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sdl-config
config.status: creating SDL.spec
config.status: creating SDL.qpg
config.status: creating sdl.pc
config.status: creating include/SDL_config.h
config.status: include/SDL_config.h is unchanged
config.status: executing default commands
Generating dependencies for ./src/SDL.c
Generating dependencies for ./src/SDL_error.c
Generating dependencies for ./src/SDL_fatal.c
Generating dependencies for ./src/audio/SDL_audio.c
Generating dependencies for ./src/audio/SDL_audiocvt.c
Generating dependencies for ./src/audio/SDL_audiodev.c
Generating dependencies for ./src/audio/SDL_mixer.c
Generating dependencies for ./src/audio/SDL_mixer_MMX.c
Generating dependencies for ./src/audio/SDL_mixer_MMX_VC.c
Generating dependencies for ./src/audio/SDL_mixer_m68k.c
Generating dependencies for ./src/audio/SDL_wave.c
Generating dependencies for ./src/cdrom/SDL_cdrom.c
Generating dependencies for ./src/cpuinfo/SDL_cpuinfo.c
Generating dependencies for ./src/events/SDL_active.c
Generating dependencies for ./src/events/SDL_events.c
Generating dependencies for ./src/events/SDL_expose.c
Generating dependencies for ./src/events/SDL_keyboard.c
Generating dependencies for ./src/events/SDL_mouse.c
Generating dependencies for ./src/events/SDL_quit.c
Generating dependencies for ./src/events/SDL_resize.c
Generating dependencies for ./src/file/SDL_rwops.c
Generating dependencies for ./src/stdlib/SDL_getenv.c
Generating dependencies for ./src/stdlib/SDL_iconv.c
Generating dependencies for ./src/stdlib/SDL_malloc.c
Generating dependencies for ./src/stdlib/SDL_qsort.c
Generating dependencies for ./src/stdlib/SDL_stdlib.c
Generating dependencies for ./src/stdlib/SDL_string.c
Generating dependencies for ./src/thread/SDL_thread.c
Generating dependencies for ./src/timer/SDL_timer.c
Generating dependencies for ./src/video/SDL_RLEaccel.c
Generating dependencies for ./src/video/SDL_blit.c
Generating dependencies for ./src/video/SDL_blit_0.c
Generating dependencies for ./src/video/SDL_blit_1.c
Generating dependencies for ./src/video/SDL_blit_A.c
Generating dependencies for ./src/video/SDL_blit_N.c
Generating dependencies for ./src/video/SDL_bmp.c
Generating dependencies for ./src/video/SDL_cursor.c
Generating dependencies for ./src/video/SDL_gamma.c
Generating dependencies for ./src/video/SDL_pixels.c
Generating dependencies for ./src/video/SDL_stretch.c
Generating dependencies for ./src/video/SDL_surface.c
Generating dependencies for ./src/video/SDL_video.c
Generating dependencies for ./src/video/SDL_yuv.c
Generating dependencies for ./src/video/SDL_yuv_mmx.c
Generating dependencies for ./src/video/SDL_yuv_sw.c
Generating dependencies for ./src/joystick/SDL_joystick.c
Generating dependencies for ./src/video/dummy/SDL_nullevents.c
Generating dependencies for ./src/video/dummy/SDL_nullmouse.c
Generating dependencies for ./src/video/dummy/SDL_nullvideo.c
Generating dependencies for ./src/audio/disk/SDL_diskaudio.c
Generating dependencies for ./src/audio/dummy/SDL_dummyaudio.c
Generating dependencies for ./src/loadso/dlopen/SDL_sysloadso.c
Generating dependencies for ./src/audio/dsp/SDL_dspaudio.c
Generating dependencies for ./src/audio/dma/SDL_dmaaudio.c
Generating dependencies for ./src/video/fbcon/SDL_fb3dfx.c
Generating dependencies for ./src/video/fbcon/SDL_fbelo.c
Generating dependencies for ./src/video/fbcon/SDL_fbevents.c
Generating dependencies for ./src/video/fbcon/SDL_fbmatrox.c
Generating dependencies for ./src/video/fbcon/SDL_fbmouse.c
Generating dependencies for ./src/video/fbcon/SDL_fbriva.c
Generating dependencies for ./src/video/fbcon/SDL_fbvideo.c
Generating dependencies for ./src/thread/pthread/SDL_systhread.c
Generating dependencies for ./src/thread/pthread/SDL_syssem.c
Generating dependencies for ./src/thread/pthread/SDL_sysmutex.c
Generating dependencies for ./src/thread/pthread/SDL_syscond.c
Generating dependencies for ./src/joystick/linux/SDL_sysjoystick.c
Generating dependencies for ./src/cdrom/linux/SDL_syscdrom.c
Generating dependencies for ./src/timer/unix/SDL_systimer.c

Thanks again Jonny… I appreciate it.

Sami_Naatanen · April 28, 2009, 10:29am

Jonathan Dearborn wrote:

The Ubuntu .so works fine for me, but the other two cause segfaults on
a skeletal program. Your debugger output hints that you’re passing
NULL to SDL_Flip(). I just tried this and it does indeed segfault.
For some reason, it seems that SDL_SetVideoMode() is failing. Try
passing 0 for the screen depth:

screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_SWSURFACE);

That way you’ll get the best that the system can give you. I would
guess that it’s just not happy giving you a 16-bit screen surface?

Some other suggestions are to stick with software surfaces
(SDL_SWSURFACE) for anything with an alpha channel or to try using
SDL_DisplayFormatAlpha() where pertinent (This also speeds up the
blitting). Unless there’s a good reason to use intermediate surfaces,
I also suggest that you just draw straight to the screen surface
instead.

I hope that helps!
Jonny D

Hi Jonny. I’ve tried messing about with my skeletal program… Same
error when changing screen depth (16, 24, 32, 0) and surface type
(SDL_SWSURFACE, SDL_HWSURFACE). It looks like my compiled libSDL
returns null for SDL_SetVideoMode() no matter what it’s passed.

This is a fairly fresh intrepid system just upgraded to jaunty… if
this persists I should probably attempt to reproduce on another machine
to see if it’s a machine or OS issue.

There’s got to be something missing from my system that would produce a
broken libSDL library after a source compile. I know it’s a bit long,
but here’s my ./configure output… There’s got to be something in
there that gives a clue: (Though the only thing that looks out of place
is the ESD version)

I assume you are trying to run the program from X11.
As you only compiled framebuffer support and no X11 support, so if you try to
run an SDL program from X11 you don’t have a working video backend and thus
SDL_SetVideoMode() will always return null.

What you need is the X11 etc dev-packages so that configure tests are able to
find them.

./configure

What you get with your current system.

Dummy video driver.

Generating dependencies for ./src/video/dummy/SDL_nullevents.c
Generating dependencies for ./src/video/dummy/SDL_nullmouse.c
Generating dependencies for ./src/video/dummy/SDL_nullvideo.c

Disk and dummy audio backends

Generating dependencies for ./src/audio/disk/SDL_diskaudio.c
Generating dependencies for ./src/audio/dummy/SDL_dummyaudio.c

FBconsole video backendOn Monday 27 April 2009 19:04:16 Trevor Bradley wrote:

Generating dependencies for ./src/video/fbcon/SDL_fb3dfx.c
Generating dependencies for ./src/video/fbcon/SDL_fbelo.c
Generating dependencies for ./src/video/fbcon/SDL_fbevents.c
Generating dependencies for ./src/video/fbcon/SDL_fbmatrox.c
Generating dependencies for ./src/video/fbcon/SDL_fbmouse.c
Generating dependencies for ./src/video/fbcon/SDL_fbriva.c
Generating dependencies for ./src/video/fbcon/SDL_fbvideo.c

Trevor_Bradley · April 28, 2009, 4:09pm

Sami N??t?nen wrote:

I assume you are trying to run the program from X11.
As you only compiled framebuffer support and no X11 support, so if you try to
run an SDL program from X11 you don’t have a working video backend and thus
SDL_SetVideoMode() will always return null.

What you need is the X11 etc dev-packages so that configure tests are able to
find them.

Aha! That was the problem. Adding “libxext-dev” to my Ubuntu system
and recompiling and installing SDL made the SDL segmentation fault go
away.

Thanks Sami!

My main app then gave me a Floating Point Exception in SDL_mixer, at
Mix_FadeInMusicPos(). Now knowing where to hunt, I think one of the
dependancies of libsdlmixer1.2-dev (or possibly libasound2-dev) fixed
that problem.

Now my program compiles and runs using local SDL libs! Except… now
the locally compiled libs also have the weird alpha blending issues I
mentioned in my original post… I just can’t win…

I’ll go back to Jonny’s original post and see if I can go back and solve
my original problem. Now I’m really suspecting missing libs (and it’s
not going to be video drivers, as my old slackware libSDL-1.2.so still
works without visual glitches)… but I’m not sure where to look.

Trevor

Trevor_Bradley · April 30, 2009, 7:29pm

Jonathan Dearborn wrote:

The Ubuntu .so works fine for me, but the other two cause segfaults on
a skeletal program. Your debugger output hints that you’re passing
NULL to SDL_Flip(). I just tried this and it does indeed segfault.
For some reason, it seems that SDL_SetVideoMode() is failing. Try
passing 0 for the screen depth:

screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_SWSURFACE);

That way you’ll get the best that the system can give you. I would
guess that it’s just not happy giving you a 16-bit screen surface?

After getting SDL to compile, but still having the same alpha problems,
I decided to create the smallest program I could that would reproduce
the alpha garbage results (originally seen here:
http://www.randomlynx.net/temp/sdl.png)

I eventually figured it out. If I set a surface’s alpha to 127:

SDL_SetAlpha(screen1, SDL_SRCALPHA, 127);

and had a screen depth of 16, the problem showed up. If the screen
depth went up to 24, the visual glitch went away.

It’s nice to have a fix, but to be honest, this still has me stumped.
The old libSDL I had on slackware works fine in 16 bit colour (even used
on the Ubuntu system), and in fact my app relied on there being 16 bit
colour (I had a routine that looked for borders in an SDL surface with
only two colours). So why the SDL lib that came with Ubuntu, or the SDL
lib built on Ubuntu have this problem, but not the older Slackware lib
has me stumped.

I guess I reprogram my app to use 24 bit colour?

Trevor

JonnyD · April 30, 2009, 7:41pm

I guess I’m at a loss as well. The Ubuntu lib works fine for me
(Debian Lenny), giving a 16-bit display with alpha blending.

I always program for arbitrary bit-depth, but expect that it will be
24-bit. Is it convenient to write your code in a more general way?
You might consider blitting to a temp 16-bit software surface and
using that for the boundary check if you want to keep your old code.

Jonny DOn Thu, Apr 30, 2009 at 3:29 PM, Trevor Bradley <trevor.bradley at shaw.ca> wrote:

Jonathan Dearborn wrote:

The Ubuntu .so works fine for me, but the other two cause segfaults on
a skeletal program. ?Your debugger output hints that you’re passing
NULL to SDL_Flip(). ?I just tried this and it does indeed segfault.
For some reason, it seems that SDL_SetVideoMode() is failing. ?Try
passing 0 for the screen depth:

screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_SWSURFACE);

That way you’ll get the best that the system can give you. ?I would
guess that it’s just not happy giving you a 16-bit screen surface?

After getting SDL to compile, but still having the same alpha problems, I
decided to create the smallest program I could that would reproduce the
alpha garbage results (originally seen here:
http://www.randomlynx.net/temp/sdl.png)

I eventually figured it out. ?If I set a surface’s alpha to 127:

SDL_SetAlpha(screen1, SDL_SRCALPHA, 127);

and had a screen depth of 16, the problem showed up. ?If the screen depth
went up to 24, the visual glitch went away.

It’s nice to have a fix, but to be honest, this still has me stumped. ?The
old libSDL I had on slackware works fine in 16 bit colour (even used on the
Ubuntu system), and in fact my app relied on there being 16 bit colour (I
had a routine that looked for borders in an SDL surface with only two
colours). ?So why the SDL lib that came with Ubuntu, or the SDL lib built on
Ubuntu have this problem, but not the older Slackware lib has me stumped.

I guess I reprogram my app to use 24 bit colour?

Trevor

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Trevor_Bradley · April 30, 2009, 7:50pm

Jonathan Dearborn wrote:

I guess I’m at a loss as well. The Ubuntu lib works fine for me
(Debian Lenny), giving a 16-bit display with alpha blending.

I always program for arbitrary bit-depth, but expect that it will be
24-bit. Is it convenient to write your code in a more general way?
You might consider blitting to a temp 16-bit software surface and
using that for the boundary check if you want to keep your old code.

Jonny D

It has to be some sort of missing or misconfigured library issue. It
appears to be isolated on my Ubuntu system, and that’s the only thing
that would explain it away.

I think I’ll recode that library to be bit-depth arbitrary, and move to
24 bits for development. It lets me move on while still being able to
look at this problem later.

Thanks for all your help Jonny!

Trevor

slouken · May 7, 2009, 12:38pm

I eventually figured it out. If I set a surface’s alpha to 127:

SDL_SetAlpha(screen1, SDL_SRCALPHA, 127);

and had a screen depth of 16, the problem showed up. If the screen
depth went up to 24, the visual glitch went away.

Out of curiousity does it work with an alpha value of 128?

See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC