> 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