Directfb Signal 11 using CVS sdl on i810

SDL Development
1

Hi All.
I’m trying to run slideshow[1] in the framebuffer. It’s an SDL app, so
I’ve tried setting SDL_VIDEODRIVER to either fbcon or directfb. However
setting it to directfb causes the app to crash.

There was a descussion earlier and a recomandation to try the CVS
version of libSDL, so I did. Both the Aug12 snapshot and checking out
the source directly, however the result is the same!? The output is
included below.

I tried to find an other simple app that could shed some light on the
problem. The best I came up with was OpenPictureSpace which seems to
work with either fbcon of directfb (even with the 1.2.7 release)!?

Running slideshow with the fbcon driver is extremely slow, so I wanted
to se how directfb would do. It’s running on an i810-all-in-one
motherboad and dfb has some support for i810 - does anyone know if
there is any performance to gain by directfb. If not the whole exercise
would be pointless for me.

[1] www.alobbs.com/slideshow/
[2] http://www.haenselmann.de/homebrew/

sys:1: DeprecationWarning: Non-ASCII character ‘\xf8’ in file first.py
on line 46, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details

   ---------------------- DirectFB v0.9.20 ---------------------
         (c) 2000-2002  convergence integrated media GmbH
         (c) 2002-2003  convergence GmbH-----------------------------------------------------------

() Single Application Core. (with MMX support) (2004-08-23 12:23)
() DirectFB/misc/memcpy: using MMXEXT optimized memcpy()
() DirectFB/InputDevice: IMPS/2 Mouse 0.9 (convergence integrated
media GmbH)
() DirectFB/InputDevice: Keyboard 0.9 (convergence integrated media
GmbH)
() MMX detected and enabled
() DirectFB/GraphicsDevice: Intel 810/810E/810-DC100/815 0.5 (Tony
Daplas)
(*) DirectFB/Layer: Enabled ‘FBDev Primary Layer’.
SDL DirectFB_SetVideoMode: 800x600 at 32, flags: 0x50000101
(!) [ 2166: 0.000] --> Caught signal 11 (at (nil), invalid address)
<–
./RUNSLIDE: line 8: 2166 Segmentation fault /usr/bin/python
first.py

–
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen

2

Martin Leopold wrote:

Hi All.

Hi,

I’m trying to run slideshow[1] in the framebuffer. It’s an SDL app,
so I’ve tried setting SDL_VIDEODRIVER to either fbcon or directfb.
However setting it to directfb causes the app to crash.

There was a descussion earlier and a recomandation to try the CVS
version of libSDL, so I did. Both the Aug12 snapshot and checking out
the source directly, however the result is the same!? The output is
included below.

Could you please post a backtrace ? Here’s how to get a backtrace :

http://www.libsdl.org/cgi/docwiki.cgi/FAQ_20Getting_20a_20backtrace

I tried to find an other simple app that could shed some light on the
problem. The best I came up with was OpenPictureSpace which seems to
work with either fbcon of directfb (even with the 1.2.7 release)!?

Running slideshow with the fbcon driver is extremely slow, so I
wanted to se how directfb would do. It’s running on an
i810-all-in-one motherboad and dfb has some support for i810 - does
anyone know if there is any performance to gain by directfb. If not
the whole exercise would be pointless for me.

It seems (after a quick look at the directfb cvs) that blit acceleration
on i810 boards is supported.

[Btw, thanks for the pointer to slideshow. I was looking for a similar
program the other day. That can be very useful for my old laptop that
can’t really afford running X]

Stephane

3

There was a descussion earlier and a recomandation to try the CVS
version of libSDL, so I did. Both the Aug12 snapshot and checking
out the source directly, however the result is the same!? The
output is included below.
Could you please post a backtrace ? Here’s how to get a backtrace :

Sure… I’ve given you two one with the 1.2.7 release and one with the
CVS version I checked out yesterday. It’s not on the i810 based machine
(it’s not that easy to get to, as its locked inside a CocaCola vending
machine), but I’m assuming its the same problem.

The CVS version is compiled with --disable-nasm. Without it my app
complains about a missing _MXX80w symbol or somehting (Debian unstable
gcc version 3.3.3)… Both are compiled with “–enable-video-directfb”.

I’ve attached some gdb output from both versions. The line that crashes
is the following:
…
memset(screen->pixels, 0, SCREEN_WIDTH * SCREEN_HEIGHT * sizeof
(Uint32));
…
“screen” in turn traces back to:
…
screen = SDL_SetVideoMode(DEFAULT_WIDTH, DEFAULT_HEIGHT, 32,
SDL_HWSURFACE|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_ANYFORMAT);
…

I tried using a different slide type (which uses an other bit of code)
and it trips over the same SEGV error when touching screen->pixels.

It seems (after a quick look at the directfb cvs) that blit
acceleration on i810 boards is supported.

Ahh… Sounds like somthing I would want =]

[Btw, thanks for the pointer to slideshow. I was looking for a
similar program the other day. That can be very useful for my old
laptop that can’t really afford running X]

You should have a look at dfbpoint which is more or less the same
thing, but has some different effects. I’m running it on an LCD screen
inside a CocaCola vending machine like an “infochannel” sort of
thing…On 08/23/04 19:53:37, Stephane Marchesin wrote:

–
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen
-------------- next part --------------
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-linux”…(no debugging symbols found)…
(no debugging symbols found)…[New Thread 16384 (LWP 26445)]
(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…[New Thread 32769 (LWP 26447)]
[New Thread 16386 (LWP 26448)]
[New Thread 32771 (LWP 26449)]
[New Thread 49156 (LWP 26450)]
[New Thread 65541 (LWP 26451)]
[New Thread 81926 (LWP 26452)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 26445)]
0x401233ab in memset () from /lib/libc.so.6
#0 0x401233ab in memset () from /lib/libc.so.6
#1 0x4047462c in Stars::Draw(SDL_Surface*) (this=0x81f3b98, screen=0x819f230) at Stars.cpp:62
#2 0x4047168d in Page::Draw(SDL_Surface*) (this=0x81f3b60, screen=0x819f230) at Page.cpp:92
#3 0x404738e4 in Presentation::Run() (this=0x814c408) at Presentation.cpp:227
#4 0x4047b6a5 in _wrap_Presentation_Run (self=0x0, args=0x0) at slideshow_wrap.cxx:1089
#5 0x080fdd5a in PyCFunction_Call ()
#6 0x0805b989 in PyObject_Call ()
#7 0x080abc14 in PyEval_CallObjectWithKeywords ()
#8 0x080a9f68 in Py_MakePendingCalls ()
#9 0x080aa6bc in PyEval_EvalCodeEx ()
#10 0x080ab829 in PyEval_CallObjectWithKeywords ()
#11 0x080ab66c in PyEval_CallObjectWithKeywords ()
#12 0x080a9b2e in Py_MakePendingCalls ()
#13 0x080aa6bc in PyEval_EvalCodeEx ()
#14 0x080aceb9 in PyEval_EvalCode ()
#15 0x080d903b in PyRun_FileExFlags ()
#16 0x080d87bf in PyRun_SimpleFileExFlags ()
#17 0x08054e95 in Py_Main ()
#18 0x080549eb in main ()
(gdb)
-------------- next part --------------
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-linux”…(no debugging symbols found)…
(no debugging symbols found)…[New Thread 16384 (LWP 31035)]
(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…(no debugging symbols found)…[New Thread 32769 (LWP 31037)]
[New Thread 16386 (LWP 31038)]
[New Thread 32771 (LWP 31039)]
[New Thread 49156 (LWP 31040)]
[New Thread 65541 (LWP 31041)]
[New Thread 81926 (LWP 31042)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31035)]
0x401233ab in memset () from /lib/libc.so.6
#0 0x401233ab in memset () from /lib/libc.so.6
#1 0x4047462c in Stars::Draw(SDL_Surface*) (this=0x81f4078, screen=0x819edb8) at Stars.cpp:62
#2 0x4047168d in Page::Draw(SDL_Surface*) (this=0x81f4040, screen=0x819edb8) at Page.cpp:92
#3 0x404738e4 in Presentation::Run() (this=0x814c408) at Presentation.cpp:227
#4 0x4047b6a5 in _wrap_Presentation_Run (self=0x0, args=0x0) at slideshow_wrap.cxx:1089
#5 0x080fdd5a in PyCFunction_Call ()
#6 0x0805b989 in PyObject_Call ()
#7 0x080abc14 in PyEval_CallObjectWithKeywords ()
#8 0x080a9f68 in Py_MakePendingCalls ()
#9 0x080aa6bc in PyEval_EvalCodeEx ()
#10 0x080ab829 in PyEval_CallObjectWithKeywords ()
#11 0x080ab66c in PyEval_CallObjectWithKeywords ()
#12 0x080a9b2e in Py_MakePendingCalls ()
#13 0x080aa6bc in PyEval_EvalCodeEx ()
#14 0x080aceb9 in PyEval_EvalCode ()
#15 0x080d903b in PyRun_FileExFlags ()
#16 0x080d87bf in PyRun_SimpleFileExFlags ()
#17 0x08054e95 in Py_Main ()
#18 0x080549eb in main ()
(gdb)

4

Martin Leopold wrote:

There was a descussion earlier and a recomandation to try the CVS
version of libSDL, so I did. Both the Aug12 snapshot and checking
out the source directly, however the result is the same!? The
output is included below.

Could you please post a backtrace ? Here’s how to get a backtrace :

Sure… I’ve given you two one with the 1.2.7 release and one with the
CVS version I checked out yesterday. It’s not on the i810 based
machine (it’s not that easy to get to, as its locked inside a
CocaCola vending machine), but I’m assuming its the same problem.

The CVS version is compiled with --disable-nasm. Without it my app
complains about a missing _MXX80w symbol or somehting (Debian
unstable gcc version 3.3.3)…

That should be fixed in current CVS, please report if it doesn’t work.

Both are compiled with “–enable-video-directfb”.

I’ve attached some gdb output from both versions. The line that
crashes is the following:
…
memset(screen->pixels, 0, SCREEN_WIDTH * SCREEN_HEIGHT * sizeof
(Uint32));
…
“screen” in turn traces back to:
…
screen = SDL_SetVideoMode(DEFAULT_WIDTH, DEFAULT_HEIGHT, 32,
SDL_HWSURFACE|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_ANYFORMAT);
…

After a quick look at the slideshow sources, it seems that it doesn’t
lock the hardware video surface.
So it seems to be a bug in slideshow. Try adding
SDL_LockSurface/SDL_UnlockSurface around the direct pixel acccess routines.

[Btw, thanks for the pointer to slideshow. I was looking for a
similar program the other day. That can be very useful for my old
laptop that can’t really afford running X]

You should have a look at dfbpoint which is more or less the same
thing, but has some different effects. I’m running it on an LCD
screen inside a CocaCola vending machine like an “infochannel” sort
of thing…

I’ll look at this, thanks.

Stephane> On 08/23/04 19:53:37, Stephane Marchesin wrote:

5

The CVS version is compiled with --disable-nasm. Without it my app
complains about a missing _MXX80w symbol or somehting (Debian
unstable gcc version 3.3.3)…
That should be fixed in current CVS, please report if it doesn’t
work.

I just tried it again and today it seems to work!? Anyway… I must have
made a mistake yesterday.

After a quick look at the slideshow sources, it seems that it doesn’t
lock the hardware video surface.
So it seems to be a bug in slideshow. Try adding SDL_LockSurface/
SDL_UnlockSurface around the direct pixel acccess routines.

And now it seems to work like charm! Thank you for debuging the
slideshow app! (just adding a bit to my list of slideshow patches =).On 24-08-2004 14:07:19, Stephane Marchesin wrote:

–
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen

6

Martin Leopold wrote:

memset(screen->pixels, 0, SCREEN_WIDTH * SCREEN_HEIGHT * sizeof
(Uint32));

I guess you meant this:

memset(screen->pixels, 0, screen->h * screen->pitch);--

Christian
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040824/cd9e8b0a/attachment.pgp