Bug 96409 – SDL_CreateThread leaks virtual address space

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description qube99 2005-06-17 12:51:13 UTC]

SDL_CreateThread is supposed to create a thread that upon returning ends the 
thread cleanly.  Instead, about 2MB of address space is not cleared up when 
the function returns. 

Reproducible: Always
Steps to Reproduce:
1.  Create SDL thread. 
2.  Return from thread, hence ending thread. 
3.  Watch the process' virtual size. 
 



Gentoo Base System version 1.4.16 
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, 
glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r9 i686) 
================================================================= 
System uname: 2.6.11-gentoo-r9 i686 AMD Athlon(tm) Processor 
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May 12 2005, 00:28:03)] 
ccache version 2.2 [enabled] 
dev-lang/python:     2.3.5 
sys-apps/sandbox:    [Not Present] 
sys-devel/autoconf:  2.13, 2.59-r6 
sys-devel/automake:  1.9.5, 1.5, 1.7.9-r1, 1.4_p6, 1.6.3, 1.8.5-r3 
sys-devel/binutils:  2.11.92.0.12.3-r2, 2.16-r1 
sys-devel/libtool:   1.5.16 
virtual/os-headers:  2.6.8.1-r2 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CFLAGS="-march=athlon-xp -O2 -pipe" 
CHOST="i686-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-march=athlon-xp -O2 -pipe" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoaddcvs autoconfig ccache distlocks fixpackages sandbox sfperms 
strict userpriv" 
GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo 
ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ ftp://gentoo.ccccom.com 
http://gentoo.netnitco.net" 
MAKEOPTS="-j2" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/mnt/misc/portage/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/usr/local/portage" 
SYNC="rsync://rsync.gentoo.org/gentoo-portage" 
USE="x86 3dnow 3dnowex X Xaw3d a52 aac aalib aim alsa apm arts asm avi berkdb 
bitmap-fonts bonobo bzlib cdparanoia cdr crypt cscope curl divx4linux doc dv 
dvd dvdr eds emboss encode esd evo examples exif fam fbcon ffmpeg flac 
foomaticdb fortran gb gcj gd gdbm ggi gif gmp gnome gnustep gpm gstreamer gtk 
gtk2 gtkhtml guile icq imagemagick imlib java jpeg junit kde kdeenablefinal 
kdexdeltas ldap lesstif libg++ libwww live lzo mad mikmod mjpeg mmx mmxext mng 
motif mozcalendar mozilla mozsvg mp3 mpeg mysql mythtv nas ncurses network nls 
objc offensive ogg oggvorbis opengl oscar oss pam pdflib perl pic pie png 
python qt quicktime readline real rtc ruby samba scanner sdl slang softmmu sox 
spell sse ssl svg svga tcltk tcpd tetex theora threads tiff truetype 
truetype-fonts type1-fonts unicode usb v4l v4l2 vcd videos vorbis win32codecs 
wxwindows xine xinerama xml xml2 xmms xv xvid xvmc yahoo zlib userland_GNU 
kernel_linux elibc_glibc" 
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

[Comment 1 Jakub Moc (RETIRED) 2005-06-17 12:53:31 UTC]

*** Bug 96408 has been marked as a duplicate of this bug. ***

[Comment 2 qube99 2005-06-17 12:54:28 UTC]

Created attachment 61410 [details]
Example program to demonstrate leak

To make the pthread version:

gcc -o thread_waste thread_wate.c -lpthread

To make the SDL version:

gcc -o sdl_thread_waste thread_waste.c -lSDL -DUSE_SDL

Run [sdl_]thread_waste <some time> and compare the virtual sizes.  A test run
of 20 or 30 seconds should be enough time to clearly observe the phenomenon. 
My libsdl is 1.2.8-r1.	I'm also posting a bug report to libsdl's bug list.

[Comment 3 SpanKY 2005-06-17 17:20:34 UTC]

please take this issue upstream to the libsdl mailing lists since you understand
the problem a lot better than us :)