C.W. Betts 2009-10-19 19:16:41 PDT
In 64-bit libraries, the fork reference is a different size than in 32-bit.
Apple has tried to help this transition by making a typedef called FSIORefNum,
but it is only available in Mac OS X 10.5 headers or later. I first noticed
this bug in Mac OS X's CD player code, and the patch is set to fix it
accordingly. This might also be an issue in SDL_QuartzVideo.m
--HG--
branch : SDL-1.2
Apply patch to first unlock the CD before trying to eject it. Since
SDL doesn't seem to have lock/unlock primitives, this looks like the
right thing to do.
Fixes audio/tcd's eject function too.
--HG--
branch : SDL-1.2
From: c2woody@gmx.net
Subject: [SDL] SDL 1.2 doube free/pointer zeroing missing
Hello,
this is about a crash/debug breakage for the current SDL 1.2
source tree (today's svn checkout, same problem in 1.2.13 and
before as far as relevant).
In some places memory is free()d but the associated pointer
is not zeroed, leading to for example double free()s.
For me this happened because SDL_StopEventThread() was executed
twice (during restart of the subsystems), once for the close
down in SDL_VideoQuit() and once at the startup, right at the
beginning of SDL_StartEventLoop(). Thus the code
SDL_DestroyMutex(SDL_EventQ.lock);
(see SDL_events.c) was called twice and executed the SDL_free(mutex);
twice as well, leading to a crash (msvc 64bit for which it was noticed).
I've tried to check all other occurrences of SDL_free and similar
code in msvc, see the attached patch (udiff against revision 4082).
Non-windows only codepaths have neither been checked nor touched.
Comments/ideas welcome.
Attached patch: NULLifies some pointers after they have been free()d.
--HG--
branch : SDL-1.2
From: Calvin Vette
Subject: Fix to compile SDL-1.2 SVN on OS X Leopard
I found I needed to add a conditional check for Leopard to compile
cleanly on 1.2-SVN (20071114):
#include <AudioUnit/AudioUnit.h>
#ifdef AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER
#include <AudioUnit/AUNTComponent.h>
#endif
where there is now just:
#include <AudioUnit/AudioUnit.h>
--HG--
branch : SDL-1.2
From: Bob Ippolito
Subject: SDL trunk (r2346) and Mac OS X
As for all the Carbon warnings.. the two File Manager ones should be
easy to get rid of, the QuickDraw ones won't be so easy since that
requires actual refactoring.
PBUnmountVol -> FSEjectVolumeSync
FSClose -> FSCloseFork
Date: Fri, 13 Jan 2006 18:09:45 -0500
From: mhall4400 vipmail kvcc edu
Subject: Possible SDL bug
Greetings
I believe Ive come across a bug in your SDL product (1.2.9), in the CD-ROM
control portion of the library.
When calling the SDL_CDPlay() function to play the last track of a CD using the
offset and length from an SDL_CD structure generated by SDL_CDOpen(), I get the
following error from a call to SDL_Error():
mciSendCommand() error: The specified parameter is out of range for the
specified command.
The code returning the error is:
SDL_CDPlay(g_playingDriveSDLCD,
g_playingDriveSDLCD->track[trackNumberInt].offset,
g_playingDriveSDLCD->track[trackNumberInt].length)
Subtracting one from the length of the provided length seems to repair the
problem:
SDL_CDPlay(g_playingDriveSDLCD,
g_playingDriveSDLCD->track[trackNumberInt].offset,
(g_playingDriveSDLCD->track[trackNumberInt].length) - 1)
Ive replicated this problem on Windows 98 SE (several months since last
patch), fully-patched Window ME, seldom-patched Windows XP SP1, and
fully-patched Windows XP SP2.
While investigating the issue, I came across a line in your librarys win32
source code in file \src\cdrom\win32\SDL_syscdrom.c (source code zip archive
from your download page), function: SDL_SYS_CDGetTOC(), line 226 where you add
1 to the value for length to fix MCI last track length bug. This may be the
source of the issue (because subtracting 1 from the length seems to resolve the
issue). Microsoft may have patched the referenced bug since you wrote that
line.
Mike Hall
From: Hayashi Naoyuki
Subject: Re: [SDL] CVS stable again, please update SDL ports
Some problems are caused on Tru64 UNIX.
If applying SDL12-osf1.path, these problems are fixed.
1. configure-script say "recursive mutexes... no" and "pthread
semaphores... no".
checking for pthreads... yes
checking for recursive mutexes... no
checking for pthread semaphores... no
This is because it compiled without pthread_cflags and pthread_lib when
checking recursive mutexes and pthread semaphores.
2. Compiling src/audio/mme/SDL_mmeaudio.c fails.
cc: Severe: ./src/audio/mme/SDL_mmeaudio.c, line 25: Cannot find file
<mme_api.h> specified in #include directive. (noinclfilef)
#include <mme_api.h>
-^
This is because BUILD_CFLAGS is wrong.
3. Compiling src/cdrom/osf/SDL_syscdrom.c fails.
cc: Warning: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Too few actual
parameters in the invocation of the macro "SDL_stack_alloc". (toofewactuals)
cdpath = SDL_stack_alloc(len);
------------------------------------^
cc: Error: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Invalid expression.
(badexpr)
cdpath = SDL_stack_alloc(len);
-----------------^
SDL_stack_alloc is defined in include/SDL_stdinc.h.
#define SDL_stack_alloc(type, count) (type*)alloca(sizeof(type)*count)
4. Linking fails if running configure with --enable-x11-shared=yes.
/usr/ccs/bin/ld:
Warning: Unresolved:
p_XData32
5. Compiling src/video/x11/SDL_x11dyn.c fails if running configure with
--enable-x11-shared=no.
cc: Error: ./src/video/x11/SDL_x11sym.h, line 149: In this statement,
"_SmtBufferOverflow" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtBufferOverflow,(Display *dpy,register smtDisplayPtr))
^
cc: Error: ./src/video/x11/SDL_x11sym.h, line 150: In this statement,
"_SmtBufferOverflow" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtBufferOverflow,(Display *dpy,register smtDisplayPtr))
^
cc: Error: ./src/video/x11/SDL_x11sym.h, line 150: In this statement,
"_SmtIpError" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtIpError,(Display *dpy,register smtDisplayPtr, int))
^
FIXME:
Change #include <stdlib.h> to #include "SDL_stdlib.h"
Change #include <string.h> to #include "SDL_string.h"
Make sure nothing else broke because of this...
requested this effort on the mailing list, apparently because of binary
compatibility issues between 10.4 and earlier systems (or gcc4 and earlier
compilers?).
Works fine with SDL12/test/testcdrom.c, with this command line:
./testcdrom -status -list -play -sleep 5000 -pause -sleep 3000 -resume \
-sleep 5000 -stop -sleep 3000 -play -sleep 3000 -stop \
-sleep 3000 -eject
Unix Makefiles work, XCode project still need updating for new filenames.
"I'm on Mac OS 10.3.9 with a CVS SDL 1.2.9.
My understanding is that SDL_CDResume is supposed to resume play after
calling SDL_CDPlay. It doesn't on my system. It returns 0 but nothing happens.
Any ideas?
Thanks.
Mike Benfield"
--ryan.
From: Johannes Schmidt
Subject: [PATCH] Re: [SDL] SDL 1.2.8 Prerelease
On Saturday 18 December 2004 13:59, Stephane Marchesin wrote:
> >#error "The kernel sources in /usr/src/linux are not yet configured."
> >#error "Please run 'make cloneconfig && make dep' in /usr/src/linux/"
> >#error "to get a kernel that is configured like the running kernel."
> >#error "Alternatively, you can copy one of the config files"
> >#error "arch/$ARCH/defconfig.* to .config, and run"
> >#error "'make oldconfig && make dep' to configure the kernel"
> >#error "for that configuration."
> >-
>
> That's the Suse kernel sources...
> I think the only way out is to add a test in ./configure
Attached is a patch (it works for me[TM]) which adds a CheckLinuxVersion() to
configure.in and a check for HAVE_LINUX_VERSION_H to
src/cdrom/linux/SDL_syscdrom.c.
From: Hayashi Naoyuki
Subject: SDL patch for Tru64 UNIX 4.0X
SDL-1.2.8 support only Tru64 5.X.
This patch is for Tru64 UNIX 4.X.(tested on Tru64 UNIX 4.0G and 5.1B)
SDL-1.2.8/configure.in:
ld doesn't accept -pthread option.
cc -pthread has same effect as -D_REENTRANT when compiling,
and has same effect as -lpthread -lexc when linking.
SDL-1.2.8/include/begin_code.h:
Old Compaq C Compiler accept not inline but __inline.
SDL-1.2.8/src/audio/SDL_mixer_MMX.c:
SDL-1.2.8/src/audio/SDL_mixer_MMX.h:
Old Compaq C Compiler doesn't accept //.
SDL-1.2.8/src/cdrom/osf/SDL_syscdrom.c:
When becoming Tru64 v5.0 from Tru64 v4.0,
the arrangement of the cd-rom device was changed.
From: Stephane Marchesin
Subject: Re: [SDL] Problem compiling SDL 1.2.7
- there is a bug that was introduced in the kernel headers for 2.6.9
which is fixed in 2.6.10. This bug *will* byte when compiling the cdrom
subsystem. A patch that works around this bug is attached. Note that
users affected are not those running 2.6.9, but those using the 2.6.9
kernel headers for their system (i.e. whose libc is built against 2.6.9
headers).
From: "A. Umbach"
Subject: Patch for bug in SDL cdrom resume handling
Black| pointed out a bug on #sdl today, that when you pause CD playback,
and then Resume it, it'll play until the end of the disk, and not until
the track you specified.
Attached is a patch that fixes the issue, by saving the desired end position
in the SDL_CD struct, and seting it again upon resume
- Andreas
From: Hayashi Naoyuki
Subject: Re: Tru64 cdrom and pthread option fix
I wrote
/* Some CD-ROM drives cannot play the first 150 frames. */
in src/cdrom/osf/SDL_syscdrom.c
and
Some CD-ROM drives(ex. TEAC CD-532E) cannot play first 150 frames(aka gap).
but this is not right.
It is written in MMC that LBA = 4500*M + 75*S + F - 150.
From: Hayashi Naoyuki
Subject: Tru64 cdrom and pthread option fix
SDL-1.2.7/src/cdrom/osf/SDL_syscdrom.c Fixes
Some CD-ROM drives(ex. TEAC CD-532E) cannot play
first 150 frames(aka gap).
CheckDrive() fix.
The end of comment is "* /" in AddDrive().
SDL-1.2.7/configure.in Fixes
Add *-*-osf pthread option and
delete line SDL_LIBS="$SDL_LIBS -lrt".
