Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
On Fri, 27 Feb 2004 17:37:48 +0100 (CET)
Frederic BOUVIER wrote:
Erik Hofman wrote:
David Megginson wrote:
Martin Spott wrote:
Great idea - unfortunately 'fgfs' now dies with a segmentation fault
just a split second after the FlightGear window appears (Linux),
Yes, I was using the wrong executable to test it. Give me about an
hour, and I'll revert if I cannot fix the problem.
There seems to be a problem with glut.
It dumps core somewhere between idle_state = 1 and idle_state =2 in
fgIdleFunction().
Same problem with MSVC. fgReshape is called before viewmgr is
initialized in main.cxx line 1335 :
FGViewMgr *viewmgr = globals-get_viewmgr();
for ( int i = 0; i viewmgr-size(); ++i ) {
viewmgr-get_view(i)-
set_aspect_ratio((float)view_h / (float)width);
}
viewmgr is 0x000
Is this the same as I'm seeing here ?
$ fgfs --log-level=bulk
(...)
Initializing splash screen
Segmentation fault (core dumped)
$ gdb fgfs
(...)
#0 0x08053c4f in fgReshape(int, int) (width=1400, height=1050) at stl_iterator.h:593
593 __normal_iterator(const _Iterator __i) : _M_current(__i) { }
(gdb) backtrace
#0 0x08053c4f in fgReshape(int, int) (width=1400, height=1050) at stl_iterator.h:593
(gdb) list
588 typedef typename iterator_traits_Iterator::pointer pointer;
589
590 __normal_iterator() : _M_current(_Iterator()) { }
591
592 explicit
593 __normal_iterator(const _Iterator __i) : _M_current(__i) { }
594
595 // Allow iterator to const_iterator conversion
596 templatetypename _Iter
597 inline __normal_iterator(const __normal_iterator_Iter, _Container __i)
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
It's fixed in CVS now... Thanks ! -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
Martin Spott wrote: Great idea - unfortunately 'fgfs' now dies with a segmentation fault just a split second after the FlightGear window appears (Linux), Yes, I was using the wrong executable to test it. Give me about an hour, and I'll revert if I cannot fix the problem. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
David Megginson wrote: Martin Spott wrote: Great idea - unfortunately 'fgfs' now dies with a segmentation fault just a split second after the FlightGear window appears (Linux), Yes, I was using the wrong executable to test it. Give me about an hour, and I'll revert if I cannot fix the problem. There seems to be a problem with glut. It dumps core somewhere between idle_state = 1 and idle_state =2 in fgIdleFunction(). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
David Megginson wrote: Martin Spott wrote: Great idea - unfortunately 'fgfs' now dies with a segmentation fault just a split second after the FlightGear window appears (Linux), Yes, I was using the wrong executable to test it. Give me about an hour, and I'll revert if I cannot fix the problem. The idea is good - don't dump it, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
Erik Hofman wrote:
David Megginson wrote:
Martin Spott wrote:
Great idea - unfortunately 'fgfs' now dies with a segmentation fault
just a split second after the FlightGear window appears (Linux),
Yes, I was using the wrong executable to test it. Give me about an
hour, and I'll revert if I cannot fix the problem.
There seems to be a problem with glut.
It dumps core somewhere between idle_state = 1 and idle_state =2 in
fgIdleFunction().
Same problem with MSVC. fgReshape is called before viewmgr is
initialized in main.cxx line 1335 :
FGViewMgr *viewmgr = globals-get_viewmgr();
for ( int i = 0; i viewmgr-size(); ++i ) {
viewmgr-get_view(i)-
set_aspect_ratio((float)view_h / (float)width);
}
viewmgr is 0x000
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
Martin Spott wrote: The idea is good - don't dump it, Thanks, but it's going to be too much work for now -- there are some bizarre interdependencies. For example, FGInterface, the FDM base class that should know nothing about 3D models, pokes around inside the aircraft model when the FDM is initialized (!!). Whenever GLUT resizes the screen, the resize function has to poke around inside the view manager. And so on. The way to fix all this is to decouple the subsystems using properties so that there is no init-order dependency (and no need for unrelated subsystems to know about other subsystems' internals), but I see at least 4-8 hours' work sorting out the mess, so it won't be this week. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
On 2/27/04 at 11:56 AM David Megginson wrote: The way to fix all this is to decouple the subsystems using properties so that there is no init-order dependency (and no need for unrelated subsystems to know about other subsystems' internals), but I see at least 4-8 hours' work sorting out the mess, so it won't be this week. Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
David Luff wrote: Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything). Hmmm, the tile manager *needs* to be initialized before the FDM because the FDM *needs* to know ground elevation for ground trimming, and we can't determine that until the local tile is loaded. We never used to load a set of tiles around (0,0) so I'm not sure why that is. The view manager code is very complex and to be honest I've never quite tracked with the latest changes in it. There may be some odd dependency there. I have also seen some wierdness in the tile scheduling/caching lately too. I'm not sure what's going on there. I started to investigate, but ran out of time the day I was looking at it. It seems like at times we get into a situation where the tile cache isn't big enough for the set of local tiles and it thrashes. That shouldn't happen, but there are some wierd view manager dependencies in there that I'm not even close to understanding. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
Curtis L. Olson said: David Luff wrote: Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything). Hmmm, the tile manager *needs* to be initialized before the FDM because the FDM *needs* to know ground elevation for ground trimming, and we can't determine that until the local tile is loaded. We never used to load a set of tiles around (0,0) so I'm not sure why that is. The view manager code is very complex and to be honest I've never quite tracked with the latest changes in it. There may be some odd dependency there. I have also seen some wierdness in the tile scheduling/caching lately too. I'm not sure what's going on there. I started to investigate, but ran out of time the day I was looking at it. It seems like at times we get into a situation where the tile cache isn't big enough for the set of local tiles and it thrashes. That shouldn't happen, but there are some wierd view manager dependencies in there that I'm not even close to understanding. IIRC there are some issues in relation to tile centers. Off hand I can't recall why, but I think the answer to both the FDM and tile center dependencies lie in the FGLocation class. Changing that to reference the property tree elements may be the ticket. It might be best if I take a look at what would be required to unravel this, since I was the last to work on it. I'll report back in the next day or two. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
On Fri, 27 Feb 2004 11:25:00 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David Luff wrote: Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything). Hmmm, the tile manager *needs* to be initialized before the FDM because the FDM *needs* to know ground elevation for ground trimming, and we can't determine that until the local tile is loaded. ..ok, the FDM needs to put its feet on something, but _does_ FG need to _show_ that first tile? Or, can FG close its eyes, as in Is there enough visibility? ..ignore my dumb question if it doesn't help weed out red herrings. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main
On Friday 27 February 2004 17:25, Curtis L. Olson wrote: David Luff wrote: Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything). Hmmm, the tile manager *needs* to be initialized before the FDM because the FDM *needs* to know ground elevation for ground trimming, and we can't determine that until the local tile is loaded. We never used to load a set of tiles around (0,0) so I'm not sure why that is. The view manager code is very complex and to be honest I've never quite tracked with the latest changes in it. There may be some odd dependency there. I have also seen some wierdness in the tile scheduling/caching lately too. I'm not sure what's going on there. I started to investigate, but ran out of time the day I was looking at it. It seems like at times we get into a situation where the tile cache isn't big enough for the set of local tiles and it thrashes. That shouldn't happen, but there are some wierd view manager dependencies in there that I'm not even close to understanding. Curt. Re the start-up at 0,0: If you start FG with Atlas already running, you'll see that the initial position given out to Atlas is always 0,0. i.e. the Atlas display will jump to 0,0 before jumping back to the specified starting location. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
