Hiho,

generally scorched3d works very fine, but there are a few problems; 2 tiny problems...

It crashes after a short time. The solution was do disable the birds' sounds. I don't need these sounds, but I was wondering that it solved the problem.

Everytime when I quit scorched, it exits with an error message (I have read already the problem here in the forum, but no solution). The message doesn't matter, but, I have no idea what could be the reason.


...and 1 medium (the main) problem:

I am using 2.6.17-gentoo-r8 with gcc-4.1.1. To be able to switch between gnome and the fullscreen-scorched, I am running 2 instances of x. In gnome, sometimes after a few seconds, scorched terminates with the message "The scorched process terminated unexpectedly". A few month ago (or some more), there were no problems when staying in gnome for a while. The differences in this time spread were:

scorched3d: 39 -> 40
gcc: 3.4.6 -> 4.1.1
xorg-x11: 6.? to 7.0
Of course another kernel and another version of nvidia-drivers (don't know the version, but kernel was 2.6).

The kernel can't be the problem. I think, the nvidia-drivers are not the reason, because the game runs when not shifting to the other x instance. I compiled scorched with the old gcc, but the problem was still present. The new xorg _could_ cause the problem but I don't think so, because when the "in_gnome_time" is only about a few seconds, scorched continuous normally.

Is the new version of the app (scorched) the reason? I don't think so, because the other instance is "out of the app's range": The app doesn't know if the user is on tty7 or tty8. So, what can cause this problem?

There is enough memory left for scorched. I can wait ... and wait ... and *plop* cpu load goes down from 100% usage to the usual 5%. Even if I do nothing, not starting another app etc..


thanks for help and any ideas, helpless regards,
Christian

If sound is causing it to crash with the boids, have you tried disabling sound altogether to see if that fixes the switch crash?

I have disabled all 3 sound options, but it didn't help.

What's it (S3D) doing when you switch to the other X server.

I am running gnome on tty7 and s3d on tty8. I start a s3d game (now fullscreen), start playing. If dead, I switch to tty7:

On the desktop applet I can see the cpu load (100%) and hear the sounds of s3d, so I know, that s3d is still running. If I switch back fast enough, I can continue with the game - but when waiting too long, the cpu load goes down and the s3d sound stops.

I have already tried to close all programs running in gnome (including the desktop applet), exceptionally a terminal window for observing "top".

Is there a possibility for getting more information, e.g. a debug mode in s3d which generates a log file?

btw: Thanks for your interest, your support, and this great game

if you run scorched with the -allowexceptions flag it will create a core dump. (You'll likely need to do a "ulimit -c unlimited" as the default "max" core size is 0 for Gentoo )

Once you have that, you can check it with gdb:
gdb /usr/games/bin/scorched3d core.xxxxx
Do a "where" in gdb and it should provide a clue as to what's going wrong.

cbx

I'd suggest to not run the game fullscreen, just a use a windows nearly as big as your screen res, and keep it on one single X-display.

NVidia drivers (always had trouble with those) or perhaps scorched3d might assume they have an exclusive access to the video card when running fullscren, and forget some other-apps-friendly checks that might lead to your problem...

I don't understand what ulimit does. In manual page:

DESCRIPTION
The ulimit utility shall set or report the file-size writing limit imposed on files written by the shell and its child processes (files of any size may be read). Only a process with appropriate privileges can increase the limit.

Sounds for me like a "maximal file write size": If this would be 0, no file could be written? "ulimit" answers with "unlimited" - nothing to do ... and in man page there is no parameter "-c", only "-f".

Ok, I have started s3d with "xinit /usr/games/bin/scorched3d -allowexceptions -- :1". Like expected, after connecting to a server and switching to gnome, the current game has quit, and on tty8 the familiar error message was poped up. I clicked "quit", the x session closed, back in console, but no dump file present (find ~/ -iname "*core*"). What did I wrong?

[ADDITION#1] Perhaps the core dump will not be created, because not the whole scorched ist terminating, only a child-process(?)?


@DeVice
Yes, your suggestion is not bad. Full resolution mode on another desktop is almost the same, except the weapon choice must be done via menu (the gnome panels are disturbing), and it doesn't look as nice as in fullscreen. There is even an advantage: Swtiching between s3d and eg. opera is faster, because it is the same x-instance.

But, a few month ago, the switching between the x instances worked, and I can't cotton on to this.


[ADDITION#2]
When the error occurs, other players on the server get the message, that is was a usual disconnect, not "... was kicked". This means that it is a "controlled crash". This is a conflict for me: The application is quiting without user-request, with an error message, but it is not a real crash.

As the error message is the same like that one when quitting by user request, I would assume that the app handles these case as an usual exit. But in which case(s) s3d exits, in addition to "exit by user request"?


[ADDITION#3]
I tried the rpm packages of 39, 39.1, and 40, but all 3 versions crashed after the switch. Although I was glad to find a server running the 39.

Don't know if this helps but i do run m2 instances on my computer too; the difference is that it actually works on my pc and scorched doesn't crash; i use:

mandriva 2007 with kernel 2.6.17-5
kde
scorched3d binary from rpm V40
Nvidia GeForce 2 MX 440 with latest drivers
X version 7.1.1

so maybe it could be either kernel (low probablity i think), X version, or the gnome environment (i don't think it's this but who knows? )

The window manager can't be the reason: I switchted to console (tty3) while playing, and the error occured again

I will try to update xorg to 7.1 ...

Thanks for your help.


[ADDITION]
Updated successfully to xorg 7.1, but it doesn't fix the problem. I have installed icewm to exclude gnome as causation - but ...

This is actually the wrong man page - I have been mislead by this in the past too - check out the bash man page and search for ulimit for the proper description.

ulimit -c (in bash, which I am presuming is your shell), sets the maximum size limit for core files.

cbx

Aah, yes, now I understand

After changing the limit for core files and effecting a s3d crash, a core file has been created. Now I will try to get some useful information with gdb.

Thanks for your help, cbx!

Greetings,
Christian

[ADDITION#1]
(gdb) where
#0 0xffffe402 in __kernel_vsyscall ()
#1 0xb7f4befb in __write_nocancel () from /lib/libpthread.so.0
#2 0xb6cf5efe in _X11TransGetMyAddr () from /usr/lib/libX11.so.6
#3 0xb6cf5a4f in _X11TransWrite () from /usr/lib/libX11.so.6
#4 0xb6cfa9a7 in _XSend () from /usr/lib/libX11.so.6
#5 0xb6cfaa7b in _XReply () from /usr/lib/libX11.so.6
#6 0xb7f10ee4 in _nv000036gl () from //usr//lib/opengl/nvidia/lib/libGL.so.1
#7 0x08349170 in ?? ()
#8 0xbf7960f4 in ?? ()
#9 0x00000000 in ?? ()

This doesn't help me much ...


[ADDITION#2]
another dumb:

#0 0xb6ce0969 in _XSend () from /usr/lib/libX11.so.6
(gdb) where
#0 0xb6ce0969 in _XSend () from /usr/lib/libX11.so.6
#1 0xb6ce0a7b in _XReply () from /usr/lib/libX11.so.6
#2 0xb7ef6ee4 in _nv000036gl () from //usr//lib/opengl/nvidia/lib/libGL.so.1
#3 0x08349170 in ?? ()
#4 0xbf3d1098 in ?? ()
#5 0x00000000 in ?? ()


The information ba gdb differs, though it was the same way to cause the crash. I will create a third one.

Is there a way to resolve the ??-symbols, maybe compiling s3d with special paramters, to include debugging symbols into the executable binary?


[ADDITION#3]
Ok, this one looks like the first:

#0 0xb7e98b23 in __pthread_enable_asynccancel () from /lib/libpthread.so.0
#1 0xb7e98ee1 in __write_nocancel () from /lib/libpthread.so.0
#2 0xb6c42efe in _X11TransGetMyAddr () from /usr/lib/libX11.so.6
#3 0xb6c42a4f in _X11TransWrite () from /usr/lib/libX11.so.6
#4 0xb6c479a7 in _XSend () from /usr/lib/libX11.so.6
#5 0xb6c47a7b in _XReply () from /usr/lib/libX11.so.6
#6 0xb7e5dee4 in _nv000036gl () from //usr//lib/opengl/nvidia/lib/libGL.so.1
#7 0x08349170 in ?? ()
#8 0xbf2540e8 in ?? ()
#9 0x00000000 in ?? ()

The binary you are using has the symbols stripped from it. If you compile it from scratch you will get a binary with the symbols in it, I would send you one but its 25MB compressed.

Thought if installing s3d with "emerge scorched3d" it is "compiled from scratch"?

Now I extracted the Scorched3D-40-src.tar.gz manually, started configure and make, but I got some errors (about wxStrings). So I started an "emerge scorched3d" and canceled the process after the configure, to get the configure arguments used by emerge, and used these arguments for the manual configure. Unfortunately this second try of the make process put out some errors again:



I don't know the differences between the emerge and the manual make, as well how to create a binary with debugging symbols?


[ADDITION#1]
Now I started configure again (without the emerge's arguments) and fixed the wxString problems manually (3 little changes in 2 cpp files), but in the end I got the same errors like before when using emerge's arguments.


[ADDITION#2]
Probably I did a mistake while copying emerge's configure arguments. In a second try the manual "configure && make" ended successfull with an 24.790.271 Bytes executable. I replaced the old 2,6 MByte file with the new one, and initiated an s3d crash to get a new core dump. Unfortunately some symbols are still unresolved, although the core dump file is much bigger than the files before (now 129 MByte).




[ADDITION#3]
If only 1 x-instance is loaded (running s3d), and I switch to another terminal while playing, s3d crashes too. It is the same effect like when switching to a second x-instance, but the gdb outputs look different. Three dumps created while only 1 x-instance were running:







And, I created a vanilla kernel, but no changing

The current release version of the nvidia driver has some issues with some versions of Xorg >7.0 - try the beta driver at http://www.nzone.com/object/nzone_downl ... river.html

Also, note that "emerge scorched3d" will strip all debugging symbols - that's the way emerge does it. (I'm sure there's a way to stop it from doing it, but don't know offhand)