I just received a couple of old (yes, really old
SPARCstations. One is running Debian woody and the other one is
running Solaris. This email refers to the SPARCstation LX running
woody.
Basically, I got an SDL app compiled and it didn’t work. Then I tried
a simple SDL test app - testvidinfo and it failed too. I have attached
an strace log that shows the cause - something is trying to allocate a
heck of a lot of memory - like 260MB or so.
It seems like the problem occurs when SDL tries to initialize the
video. Or to be exact, I know it does - I got that from gdb. However
since this machine is so slow and only has 32 MB of RAM, debugging
with gdb is quite painful. Plus, I can’t figure out what the problem
is anyway.
I should add that I try to run against a remote X display, since I
lack a Sun monitor and more importantly mouse/kbd. Also, I have
verified that other X11 programs work (simple stuff like xeyes and
xlogo).–
[ Below is a random fortune, which is unrelated to the above message. ]
A good scapegoat is hard to find.
A guilty conscience is the mother of invention.
– Carolyn Wells
-------------- next part --------------
A non-text attachment was scrubbed…
Name: log.bz2
Type: application/octet-stream
Size: 4018 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020901/6856a787/attachment.obj
A follow-up on my own mail. This is the GDB backtrace:
(gdb) bt #0 0x501a7b40 in select () from /lib/libc.so.6 #1 0x503df934 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6 #2 0x503e06fc in _XRead () from /usr/X11R6/lib/libX11.so.6 #3 0x503e1eb8 in _XEatData () from /usr/X11R6/lib/libX11.so.6 #4 0x50063bd4 in SDL_XF86VidModeGetAllModeLines ()
from /usr/lib/libSDL-1.2.so.0 #5 0x5005e7c4 in X11_GetVideoModes () from /usr/lib/libSDL-1.2.so.0 #6 0x500603bc in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 #7 0x50055f54 in SDL_VideoInit () from /usr/lib/libSDL-1.2.so.0 #8 0x50036754 in SDL_InitSubSystem () from /usr/lib/libSDL-1.2.so.0 #9 0x500368dc in SDL_Init () from /usr/lib/libSDL-1.2.so.0 #10 0x000109f8 in main (argc=1, argv=0xefffe9e4) at testvidinfo.c:15–
[ Below is a random fortune, which is unrelated to the above message. ]
UNIX is hot. It’s more than hot. It’s steaming. It’s quicksilver
lightning with a laserbeam kicker.
– Michael Jay Tucker
A follow-up on my own mail. This is the GDB backtrace:
Yack, it sounds like the remote server has an incompatible version of
the XFree86 vidmode protocol. What version of X server are you running?
remote display: 4.2.0
local version: 4.1.0.1
(quite old…)–
[ Below is a random fortune, which is unrelated to the above message. ]
Rule of Defactualization:
Information deteriorates upward through bureaucracies.
I just received a couple of old (yes, really old
SPARCstations. One is running Debian woody and the other one is
running Solaris. This email refers to the SPARCstation LX running
woody.
Basically, I got an SDL app compiled and it didn’t work. Then I tried
a simple SDL test app - testvidinfo and it failed too. I have attached
an strace log that shows the cause - something is trying to allocate a
heck of a lot of memory - like 260MB or so.
It seems like the problem occurs when SDL tries to initialize the
video. Or to be exact, I know it does - I got that from gdb. However
since this machine is so slow and only has 32 MB of RAM, debugging
with gdb is quite painful. Plus, I can’t figure out what the problem
is anyway.
I should add that I try to run against a remote X display, since I
lack a Sun monitor and more importantly mouse/kbd. Also, I have
verified that other X11 programs work (simple stuff like xeyes and
xlogo).
It looks like the XFree86 extension code doesn’t check to see if the
local and remote systems are using a different byte order for the protocol
data.
I’m not sure what easy fix there is, other than just disabling those
extensions in your build of SDL, with the following configure options:
–disable-video-x11-vm --disable-video-x11-xv --disable-dga
You’re welcome to verify this and take a crack at fixing the XFree86
code, if you want.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
It looks like the XFree86 extension code doesn’t check to see if the
local and remote systems are using a different byte order for the protocol
data.
I take it back, I just checked the server code, and it is correctly swapping
the fields if the client is of differing byte order. Out of curiousity, can
you add debug code to /src/video/XFree86/Xxf86vm/XF86VMode.c and see
what the value of rep.modecount is at line 337 is? That’s the only thing
I can think of.
Again, you can disable the extension with: --disable-video-x11-vm
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
