headers
Michael Zeilfelder | 1 Mar 2006 01:39
Picon

sdl in debian-sid crashes SDL_PollEvent

Hi, i don't know much about sdl, but tried to find out why my qemu crashed since
today. I reduced the problem to the following lines:

#include <stdlib.h>
#include "SDL.h"

main(int argc, char *argv[])
{
    if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
        fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError());
        exit(1);
    }
    atexit(SDL_Quit);
	
	SDL_SetVideoMode(100, 100, 0, SDL_HWSURFACE);

	while (1)
	{
		SDL_Event ev;
		while (SDL_PollEvent(&ev)) 
		{
		}
	}	
}
I've got a callstack, but currently no self-compiled sdl, so just functions:
SDL_PumpEvents - X11_PumpEvents - X11_SetKeyboardState - X11_TranslateKey -
XLookupString - Segmentation Fault

The crash happens sometimes on start, otherwise always as soon as the mouse
enters the sdl-windows.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Zeilfelder | 1 Mar 2006 02:37
Picon

Re: sdl in debian-sid crashes SDL_PollEvent

Oh, half an hour later i got a new sdl in the debian repositories. It's fixed
with  those. You're just too fast for me :)
Permalink | Reply | 1 comment |
headers
Rhythmic Fistman | 1 Mar 2006 05:15
Picon
Gravatar

Re: Mainline vs Embedded

> From: Bob Ippolito <bob <at> redivi.com>
> On Feb 23, 2006, at 5:21 PM, Rhythmic Fistman wrote:
[...]
> > Take as an example pygame (the python SDL binding):
> > It must either
> >
> >  a) let SDL own its main, creating the necessity for SDL_python
> >     interpreter binaries.
> >
> >  b) not use SDLmain and exclude all the platforms with non-trivial
> >     src/main implementations (macosx, win32, beos).
> >
> >  c) have found some other way that we don't know about.
>
> pygame uses (c), it replicates the necessary bits of SDLmain for its
> supported platforms in such a way that makes sense for Python

Is there any reason that this replicated code couldn't be conditionally
called from SDL_Init? If not, would there be any objection to such a patch
being submitted?

The removal of control over main can be quite nasty and have subtle
consequences. One not-so-far-fetched possibility: if you don't own
main you can't reliably use sigwait or even globally set the signal
mask, because SDL may have already spawned threads that are beyond
your control. Is this the case?

RF.
Permalink | Reply | 3 comments |
headers
Sam Lantinga | 1 Mar 2006 06:15

Re: Mainline vs Embedded

> Is there any reason that this replicated code couldn't be conditionally
> called from SDL_Init? If not, would there be any objection to such a patch
> being submitted?

It's generally code that can't be called from SDL_Init(), but it's code that
you can call from your main application - that's why the various initialization
functions are defined in SDL_main.h

SDL's main() overriding is purely a convenience.  If you want to roll your
own, you're more than welcome to.  That's why the SDLmain code is all in the
public domain - for you to use/reuse/abuse as you like. :)

	-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Permalink | Reply | 2 comments |
headers
Sam Lantinga | 1 Mar 2006 06:17

Re: Latest version doesnt work with mplayer.

> 1. Im using the latest cvs version of sdl, but mplayer failed to detedct sdl
> during configure,

Try getting a clean copy of the SDL source from CVS and re-building it with
mingw32.

See ya!
	-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Permalink | Reply | 5 comments |
headers
yong | 1 Mar 2006 10:35
Picon
Favicon

Re: Latest version doesnt work with mplayer.

Sam Lantinga <slouken <at> devolution.com> writes:

> 
> > 1. Im using the latest cvs version of sdl, but mplayer failed to detedct sdl
> > during configure,
> 
> Try getting a clean copy of the SDL source from CVS and re-building it with
> mingw32.
> 
> See ya!
> 	-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
> 

Compiling works again with mplayer, thanks !!
now mplayer with sdl audio/video-out work flawlessly again :)
But still left a small bug in sdl(not sure :p)
the sdl default mode works without a problem with mplayer,
but when i change the driver to directx( -vo sdl:driver=directx),
it crahsed for me when the video start playing,
here is the part of console output:

MPlayer interrupted by signal 11 in module: decode_video
ID_SIGNAL=11
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Graham | 1 Mar 2006 10:24
Picon
Favicon

SDL_GetVideoSurface return 0 on XP?

Trying to get the current video resolution prior to SDL_SetVideoMode(). Sadly 
both SDL_GetVideoInfo() and SDL_GetVideoSurface() return 0;

Is there a pre-condition I should be aware of? Does this simply not work on XP 
or is it a problem with specific video drivers?

thanks.
Permalink | Reply | 2 comments |
headers
Sam Lantinga | 1 Mar 2006 11:02

Re: Latest version doesnt work with mplayer.

> Compiling works again with mplayer, thanks !!
> now mplayer with sdl audio/video-out work flawlessly again :)

Yay!

> do i need to attach it with gdb then send a full bug report to u? :)

Yes.
	-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Permalink | Reply | 1 comment |
headers
Ulrich von Zadow | 1 Mar 2006 11:03
Favicon

Re: Mainline vs Embedded

Sam Lantinga wrote:
>>Is there any reason that this replicated code couldn't be conditionally
>>called from SDL_Init? If not, would there be any objection to such a patch
>>being submitted?
 >
> It's generally code that can't be called from SDL_Init(), but it's code that
> you can call from your main application - that's why the various initialization
> functions are defined in SDL_main.h

I think the issue at the moment is that there's some code in the OS X main() 
that doesn't conform to this (the mail I sent on Feb. 23 contains precisely that 
code). Currently, just leaving away SDL_main is broken on OS X because of this 
issue. This code could be moved to SDL_Init without causing problems - I'm 
executing it directly before SDL_Init in libavg.

Anyway, I'd already asked Sam if a patch for this was ok and gotten a yes, but I 
probably won't have the time to do it, so...

Regards,

   Uli
Permalink | Reply | 1 comment |
headers
Giles Constant | 1 Mar 2006 12:24

Why does this click? (version 2)

Hi again,

Here's an even simpler example of something that clicks, which writes exactly 
"len" bytes directly to the "stream" pointer passed to mix(), and is 
generating audio data immediately on entry to the function.  Incidentally, 
the duration between the clicks is directly proportional to the value of 
"desired.samples" .  Is there some sort of buffering or locking thing I have 
to do?

It compiles with "gcc -Wall sdlsound.c -lSDL".

-

#include <SDL/SDL.h>
#include <SDL/SDL_audio.h>

#define sinf __builtin_sinf
#define printf __builtin_printf
#define exit __builtin_exit
#define M_PI 3.14159265358979323846

#define AUDIO_FREQ 44100;

float sine_pos = 0;
float sine_speed = M_PI * 2 * 440 / AUDIO_FREQ;

void mix(void* data, Uint8* stream, int len)
{
    Uint8* s_ptr;
    Uint8* stream_end = stream + len;
(Continue reading)

Permalink | Reply | 4 comments |

Gmane