On Saturday 10 April 2004 21:29, David Luff wrote:
Thanks very much for taking the time for digging into this in such detail.
I suspect that you and Curt have hit the nail on the head there - although
I ref and deref each use of the model, the AIMgr doesn't hold a ref to stop
deletion when
Durk Talsma writes:
Your welcome. I just tested your patch, and it works! :-) This time I
sucessully passed EHKD airport on my test circuit and made it succesfully
back to EHAM. Even made a reasonable landing. :-)
Great stuff! This is now in CVS. I was somewhat relieved to find no trace
Okay, I can confirm that the program crash also happens with a JSBSim
aircraft. I used the the A320 (sorry David, the 737 autopilot appears not to
support waypoint following, so I couldn't use it, for testing purposes).
Since threading doesn't appear to make a difference, I enabled it again
On Saturday 10 April 2004 14:18, Jon Berndt wrote:
Okay, I can confirm that the program crash also happens with a JSBSim
aircraft. I used the the A320 (sorry David, the 737 autopilot
appears not to
support waypoint following, so I couldn't use it, for testing purposes).
Since threading
I found something that might be a candidate for the overflow. Around
this timeframe, some sprintf(%f) code got added to the atis handler.
The problem is, printf() can generate almost unbounded output for very
large values* and the buffer is only 10 bytes long.
* Try this: int main() {
I just tried this fix, but I'm afraid that this didn't solve the problem. I
still got the crash. What's more worriesome is that it appears that
FlightGear-0.9.4 already has this bug. I just compiled and tested the release
version and, again, got the abort at 10 nm east of EHKD*. So I'm afraid
Durk Talsma writes:
That's what I would guess. B.t.w, I've found a way to consistently replicate
the crash, using a relatively short route (about 25 minutes). This route
requires tile e000n50, as I'm taking off from Amsterdam Schiphol, and
crashing the program at Den Helder Airport.
Andy Ross wrote:
Lee Elliott wrote:
I first reported this on 02-April and had updated from cvs two
days prior to mentioning the problem. I think the last update
I'd done before that was about two weeks earlier.
Can anyone confirm the same behavior from the 0.9.4 binaries? (I
think it branched
Erik Hofman wrote:
Andy Ross wrote:
Lee Elliott wrote:
I first reported this on 02-April and had updated from cvs two
days prior to mentioning the problem. I think the last update
I'd done before that was about two weeks earlier.
Can anyone confirm the same behavior from the
Frederic Bouvier wrote:
Erik Hofman wrote:
Andy Ross wrote:
Lee Elliott wrote:
I first reported this on 02-April and had updated from cvs two
days prior to mentioning the problem. I think the last update
I'd done before that was about two weeks earlier.
Can anyone confirm the same behavior
On Friday 09 April 2004 10:11, Erik Hofman wrote:
Andy Ross wrote:
Lee Elliott wrote:
I first reported this on 02-April and had updated from cvs two
days prior to mentioning the problem. I think the last update
I'd done before that was about two weeks earlier.
I first noticed the problem
Erik Hofman wrote:
Andy Ross wrote:
Can anyone confirm the same behavior from the 0.9.4 binaries? (I
think it branched sometime right around there.) Is there any
platform dependence to this? I have to admit it's been a long time
since I've have a single fgfs running for that long.
On Friday 09 April 2004 17:03, Andy Ross wrote:
The new fuel code went into YASim at about the same time. Can someone
try to reproduce this with a non-YASim aircraft?
Another thing to try is just to leave it running with the aircraft on
the ground, so see if maybe this is an interaction
Now, I'd like to rerun this test using a JSBsim aircraft. What's a good
JSBsim match to the 747?
You could use the 737. Just edit the engine config, CFM56_sim.xml, to reset
the TSFC value to something like 0.1
That will give you the endurance you want.
Dave
--
Lee Elliott wrote:
I first reported this on 02-April and had updated from cvs two
days prior to mentioning the problem. I think the last update
I'd done before that was about two weeks earlier.
Can anyone confirm the same behavior from the 0.9.4 binaries? (I
think it branched sometime right
I am fighting against a memory corruption for 2 hours and I solved it.
Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store
strings.
Here is the patch, hoping it will solve Curt's and Michael's problems :
D:\FlightGear\cvs\FlightGear\srccvs -z3 -q diff -u ATC/ATCmgr.cxx
Frederic Bouvier writes:
I am fighting against a memory corruption for 2 hours and I solved it.
Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store
strings.
I'll cross my fingers.
Frederic -- are the XML dialogs still working OK for you?
All the best,
David
--
From: David Megginson [EMAIL PROTECTED]
Frederic Bouvier writes:
I am fighting against a memory corruption for 2 hours and I solved it.
Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store
strings.
I'll cross my fingers.
Frederic -- are the XML dialogs still
On 1/19/03 at 10:09 PM Frederic Bouvier wrote:
I am fighting against a memory corruption for 2 hours and I solved it.
Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store
strings.
Here is the patch, hoping it will solve Curt's and Michael's problems :
Oops, sorry.
I've
Frederic Bouvier writes:
My new option parsing function is also working. You will receive it
soon.
I've got it, and will take a look as soon as I'm done rebuilding with
3.2.
Thanks,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
20 matches
Mail list logo
