> I've seen a couple of "Failed to open file" messages w/o a file,
> and decided to hunt for that one. It looks like this is only
> thrown from within simgear, but always with a path.
>
> Closer examination reveals that easyxml.cxx throws it, and uses the same
> pattern as JSB and I had recently agreed to be problematic ---
> dynamically creating things on the stack and throwing them!
>
> Either I managed to persuade JSB in a wrong C++ fact (I'm not 100% sure
> about it), or each and every "throw" throughout simgear and flightgear
> must be reviewed and such usages rewritten.
>
> One might argue that this is smth that only aids in error recovery in
> already screwed up situations, but some exceptions might be thrown to
> indicate non-globally-fatal situations --- i.e., without looking at every
> such place we can't be sure.
>
Bad news --- I've verified, and indeed this is a wrong way to throw a tmp
object out of a stack frame. It's fine as long as the catch handler is in
the same function.
If all that the catch handler does is catch smth by reference
and never access the instance, it is fine, but 1) the throw is still
unsafe 2) in this case, all that the exception object is used for
is just signal the type of exception by its C++ type, and thus
it makes more sense to have one static object of that class
for this very purpose, to save the ctor/dtor hassle.
Bottom line: sg/fg contains a lot of unsafe and unportable code
(i.e., some compilers will have it crash earlier than the others),
and a patch is needed. I'll try to work on this in this coming weekend,
time permitting. It's a lot of code to verify --
find . -name '*.[ch]*' | xargs cat | grep -c throw
gave me 66 on sg and 43 on fg.
It's a pity no exceptions like these had been thrown during the valgrind
runs some folks were running.
Vassilii
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
