On Thu Feb 3 17:30:06 CST 2005, Ampere K. Hardraade wrote:
> On February 1, 2005 03:36 pm, Dean Williams wrote:
>> The installaton at "0x0938b08b" reference memory at "0x0b41d2ff". 
The> memory could not be written!.......................whatever that
means.Perhaps this is an out of memory error?
> I have a similar problem in Linux a few weeks ago:
> If these are indeed related, that means we can duplicate the error in
> Linux and find out the exact cause of the problems.

I don't know if anything more has been done on this (I don't see
anything in the archive), but I can reproduce something very much like
this on linux.

Stock Fedora Core 2.
"2100+MHz" Athlon processor.
At least 256Mb RAM (might be 512Mb - I'll check) at 266MHz
Matrox G200 AGP video card supposedly with 3D acceleration working.
Standard 0.9.8 Flightgear plus scenery for Western Europe area.

If I just type "fgfs" or "fgfs --disable-sound", all I get is the splash
screen and plenty of disk-grinding noises followed by the splash-screen
disappearing and the single-word message "Killed" on stdout. (I tried
the --disable-sound option to try and avoid possible troubles with

I get exactly the same thing with the motherboard's native S3
"ProSavage" KN133 video card too (it has to use software rendering due
to lack of DRI support).

Interestingly, the FPS readout I see from "glxgears" is not radically
different when comparing the two video cards. (About 150 - 180fps).
This might indicate that I've not got the DRI running properly for the
G200, or that the G200 is a total turkey(*). I do know that the G200
driver reports AGP x1, whereas I believe I should be able to get at
least x2 from it.

The same RPM of FlightGear 0.9.8 runs perfectly well on a 2GHz
Intel P4 with an Nvidia Quadra graphics card (using Nvidia's binary
driver). So it's not the build per se.

I might suggest that those of us who've seen this sort of problem seem
to have slow 3D rendering. Could it be possible that FlightGear is
starting to send a screenfull of vertexes to the video card, but gives
up (due to the slow card), aborts that frame and tries to start another.
The same thing then happens again and again. This might trigger a slow
memory leak internally which eventually leads to the "killed" message
with nothing ever appearing on screen.

It does seem that the length of time between the splash-screen appearing
and the "killed" (or "aborted") message might be dependant on the amount
of RAM (or maybe the amount of swap) available.

If the rendering hypothesis above was true, presumably such a scenario
could only happen if the scene renderer thought that it should be able
to run the screen at a given FPS yet the hardware refuses to oblige.

It's just thoughts.. Anyone got any good ideas for ways to test them?
I'll run experiments on my failing machine at home if anyone has

The "correct" behaviour for FlightGear should be to run, but with a
uselessly slow frame rate on screen, surely? It used to do that, maybe
back at about 0.9.1 or 0.9.2


(*) Or both

Flightgear-devel mailing list

Reply via email to