Hi,

Sorry to have to go on with this... but I do want 
my built from source FG to work!

Anyway, I 'think' I have found a JSB 'bug', or at 
least something I do not understand...

In FGStandardAtmosphere bind(void) we have 2 typedef
  typedef double (FGStandardAtmosphere::*PMFi)(int) const;
  typedef void (FGStandardAtmosphere::*PMF)(int, double);

And then we have 2 functions GetTemperatureBias, and 
Set TemperatureBias, which are declared similarly to the
typedefs, and tied -
  PropertyManager->Tie("atmosphere/delta-T", this, eRankine,
            (PMFi)&FGStandardAtmosphere::GetTemperatureBias,
            (PMF)&FGStandardAtmosphere::SetTemperatureBias);

That is the getter declaration matches the function 
declaration...

But the 3rd tie in the bind() is -
  PropertyManager->Tie("atmosphere/P-sl-psf", this, ePSF,
            (PMFi)&FGStandardAtmosphere::GetPressureSL,
            (PMF)&FGStandardAtmosphere::SetPressureSL);

How come GetPressureSL is defined as -
 virtual double GetPressureSL(void) const
  { return SLpressure }

Here we have a function declared differently to what 
the typedef of the indexed getter pointer is...

It is the call to this 'getter' that crashes my 
system!

The rest of this is just how I tried to track this down,
and you can skip it if not in Windows, or just not 
interested ;=)) just the big tedium of bug chasing...

To rule out the Win 7 system in general downloaded and 
installed FG 2.8.0-RC4, and it worked perfectly. This time 
fgrun had all the correct paths ;=)) Thanks Fred...

Maybe I should head towards building the 64-bit 
exe, rather than this problematic 32-bit first ;=()

I then increased log level to debug, and it seems to 
consistently break after the output shown, but as we 
know this does not always really indicate where the 
real problem is...
...
Tied /ai[0]/models[0]/carrier[1]/controls[0]/turn-to-recovery-hdg[0]
Tied /ai[0]/models[0]/carrier[1]/controls[0]/turn-to-base-course[0]
Submodels: Loading AI submodels 
AI Manager: AI model return list size 2
Submodels: Loading sub submodels
trigger listener #88
trigger listener #93

See full log: 
 http://geoffair.org/tmp/templog.txt 

I tried adding --disable-ai-traffic --disable-ai-scenarios 
even --disable-ai-models, but that had no effect ;=((

See full log: 
 http://geoffair.org/tmp/templog5.txt 

So I built the MSVC10 Debug version, and ran fgfs under 
the MSVC debugger, and it certainly 'aborts' at line 589 
in props.hxx, but it is during the saveInitialState() 
call in fg_init.cxx... in copyProperties(...)... so 
seems nothing to do with AI...

At the moment of the crash, the call stack is -
>   fgfs.exe!
SGRawValueMethodsIndexed<JSBSim::FGStandardAtmosphere,double>::getValue()  Line 
589 + 0x27 bytes   C++
    fgfs.exe!SGPropertyNode::get_double()  Line 396 + 0x1b bytes    C++
    fgfs.exe!SGPropertyNode::getDoubleValue()  Line 1192 + 0x8 bytes
C++
    fgfs.exe!copyProperties(const SGPropertyNode * in, SGPropertyNode *
out, int attr_value, int attr_mask)  Line 672 + 0x8 bytes   C++
    fgfs.exe!copyProperties(const SGPropertyNode * in, SGPropertyNode *
out, int attr_value, int attr_mask)  Line 732 + 0x24 bytes  C++
    fgfs.exe!copyProperties(const SGPropertyNode * in, SGPropertyNode *
out, int attr_value, int attr_mask)  Line 732 + 0x24 bytes  C++
    fgfs.exe!copyProperties(const SGPropertyNode * in, SGPropertyNode *
out, int attr_value, int attr_mask)  Line 732 + 0x24 bytes  C++
    fgfs.exe!copyProperties(const SGPropertyNode * in, SGPropertyNode *
out, int attr_value, int attr_mask)  Line 732 + 0x24 bytes  C++
    fgfs.exe!FGGlobals::saveInitialState()  Line 414 + 0x25 bytes   C++
    fgfs.exe!fgInitSubsystems()  Line 1316  C++
    fgfs.exe!fgIdleFunction()  Line 400 + 0x5 bytes C++
    fgfs.exe!fgOSMainLoop()  Line 284 + 0x5 bytes   C++
    fgfs.exe!fgMainInit(int argc, char * * argv)  Line 537 + 0x5 bytes
C++
    fgfs.exe!main(int argc, char * * argv)  Line 251 + 0xd bytes    C++
    fgfs.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
    fgfs.exe!mainCRTStartup()  Line 371 C
    kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
    ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
    ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

Tediously tracing through some code note the following...

In props_io.cxx, while iterating nChildren = 2,
Ln 705 for(int i = 0; i < nChildren; i++), on the 
first child, i == 0, the in_child _name="jsbsim",
out_child="jsbsim", attr_value=3, attr_mask=195

The multiple copyProperties() is just as it 
iterates through children of children of children...

Ln 672: case props::DOUBLE:
   if (!out->setDoubleValue(in->getDoubleValue()))
      retval = false;
   break;
Both in and out = "fdm"

In props.cxx getDoubleValue()
 // Shortcut for common case
 if (_attr == (READ|WRITE) && _type == props::DOUBLE)
Ln 1192: return get_double()

Again in props.cxx get_double ()
 if (_tied)
Ln 396: return static_cast<SGRawValue<double>*>
  (_value.val)->getValue();

which put me in the 'problem' _getter
 fgfs.exe!SGRawValueMethodsIndexed<JSBSim::
   FGStandardAtmosphere,double>::getValue()  Line 589 + 0x27 bytes
getting the tied <JSBSim::FGStandardAtmosphere,double>

By setting a debug trap here the first call to here is to 
get_magnetos(int engine) in src\aircraft\controls.hxx, 
which I can see in disassembly is a stdcall. That is 
it ends with ret 4!

The next call to this 589 is get_carb_heat, again a 
stdcall - ends with ret 4!

But there are __cdecl on some things, like 
  call SGAnimation::animate
  add esp,18h ; fix up the stack

So, the code is a mixture of __cdecl and stdcall!
But who, what, how, is this decided? Not sure...

Now to try to back up to where JSBSim is setting 
this _getter...

This seems to be in -
src\FDM\JSBSim\models\atmosphere\FGStandardAtmosphere.cpp
v 1.21 2012/04/13 13:18:27 jberndt, so does not appear 
to be exactly 'new' code...

In bind(), the getter/setter are tied to functions 
void FGStandardAtmosphere::bind(void)
{
  typedef double (FGStandardAtmosphere::*PMFi)(int) const;
  typedef void (FGStandardAtmosphere::*PMF)(int, double);
  PropertyManager->Tie("atmosphere/delta-T", this, eRankine,
            (PMFi)&FGStandardAtmosphere::GetTemperatureBias,
            (PMF)&FGStandardAtmosphere::SetTemperatureBias);
  PropertyManager->Tie("atmosphere/SL-graded-delta-T", this, eRankine,
            (PMFi)&FGStandardAtmosphere::GetTemperatureDeltaGradient,
            (PMF)&FGStandardAtmosphere::SetSLTemperatureGradedDelta);
  PropertyManager->Tie("atmosphere/P-sl-psf", this, ePSF,
            (PMFi)&FGStandardAtmosphere::GetPressureSL,
            (PMF)&FGStandardAtmosphere::SetPressureSL);
}

These are all 'virtual' functions in FGStandardAtmosphere.h, 
replacing the base FGAtmosphere class, FGAtmosphere.h, 
which in turn replace the base.base FGModel class, FGModel.h, 
in the base.base.base FGModelFunctions, in the basex4
FGJSBBase class... but it all looks fine ;=()

But again and again I see some things are definitely 
__cdecl, like -
 push eax
 push ecx
 push edx
 push eax
 call copyProperties
 add  esp,10h
 
 And others are stdcall, like 
  push eax
  call get_throttle ; inline get_throttle(int eng)
  ret 4

Like all the FGControls - controls.hxx - all end 
with ret 4 - stdcall...

BUT, BUT, BUT, WAIT, WAIT, WAIT the function -
 virtual double GetPressureSL(void)
is NOT... it does a simple return...

All the others seem be an 'index' getter, but 
note GetPressureSL is a (void) - NO INDEX!!!

So WHY does this GetPressureSL get included in 
the above bind() where the typedef is -

typedef double (FGStandardAtmosphere::*PMFi)(int)
const;

Is this the problem? It seems to match the dialog 
report that a function pointer and a function have 
different declarations...

BAH! This seems like an endless chase ;=(( I suppose 
I just know, understand enough to get myself into 
trouble ;=))

Unless I have somehow stumbled on a real BUG, and 
it can be fixed, or someone else has some ideas I
will give it up for a while... this has already 
consumed most of today...

Meantime will continue with the big setup to be able 
to eventually build the 64-bit version... first 
re-compiling all the dependencies in 64-bits...
yuck...

Regards,
Geoff.


-------- Forwarded Message --------
> From: Geoff McLane <ubu...@geoffair.info>
> To: flightgear-devel <flightgear-devel@lists.sourceforge.net>
> Subject: Windows Abort Retry Ignore dialog at startup
> Date: Wed, 01 Aug 2012 20:38:42 +0200
> 
> Hi all,
> 
> Each, SG/FG/fgdata updated to release/2.8.0 today. 
> Full SG then FG clean and build using MSVC10 in Win 7,
> 64-bit...
> 
> That is with like -
> $ git pull origin next
> $ git fetch --all
> $ git checkout release/2.8.0
> $ git reset --hard origin/release/2.8.0
> $ git branch
>   next
> * release/2.8.0
> followed by a full clean and build in an 
> o-o-s folder...
> 
> When the splash screen is showing 'initializing 
> subsystems' after several seconds, get an ugly 
> Abort/Retry/Ignore dialog ;=((
> 
> See:
> http://geoffair.org/tmp/error-01.jpg 
> 
> Have tried Ignore, but it keeps coming back, 
> and leads to other abort dialogs...
> 
> Only console output is -
> KI226 dme indicator #0 initialized
> loading scenerio 'nimitz_demo'
> 
> And will also try turning on log level debug 
> to see if I can closer track down where and 
> when it is happening...
> 
> As can be seen in the dialog it indicates the ESP 
> was not saved across a function call and that this 
> is usually the result of a function declared with 
> one calling convention, say stdcall, while a 
> function pointer is declared with a different 
> convention like say __cdecl ;=((
> 
> Is anyone else seeing this? Seen this? Found 
> a fix? ...
> 
> And indeed the line indicated, 589, in simgear 
> prop.hxx is a call through a pointer -
>   if (_getter) { return (_obj.*_getter)(_index); }
> 
> The getter_t _getter is declared without a 
> declared calling convention like -
>   typedef T (C::*getter_t)(int) const;
> which means it would be the default, which is 
> __cdecl (/Gd) in MSVC10, as it has been for a 
> long time...
> 
> This suggest somewhere a call setting this _getter 
> pointer is passing a function declared with 
> say stdcall, fastcall or something other than 
> __cdecl...
> 
> Anyway, totally at a loss to find and fix this.
> 
> Any ideas, thoughts, things to try, very VERY 
> welcome...
> 
> Regards,
> Geoff.
> 
> PS: In not quite the same rigorous cleaning, 
> updating re-build etc, also see/seen the SAME 
> thing in XP 32-bit with MSVC8... which suggests 
> it is not the compiler version, or OS version...
> 
> And does NOT happen in Ubuntu 10.04 64-bits...
> 
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to