> I tested a little further, and learned that the stack overflow actually
> happens during Exception unwinding of an exception thrown by the
> RecursionGuard.
Just a stray thought: Thrown C++ exceptions live in their own memory area
(because their lifetime is different from the lifetime of the objects on the
stack that are destroyed). I don’t know at which point compilers actually
decide to free them – if that only happens after stack unwinding, I would not
be surprised if catching exceptions and throwing new ones in a sufficiently
deep recursion caused problems similar to this.
Also, I see a number of places in PoDoFo like this:
} catch (ArgParseException &e) {
throw ArgParseException(e.error(), toString());
}
Creating a new exception like that seems to me to defeat the whole non-slicing
purpose of catching by reference in the first place? Wouldn’t it be better if
ArgParseException had a setId(std::string const&) method and the catch clause
would call that and rethrow?
Just my €.02,
Christopher
The MathWorks GmbH | Weihenstephaner Str. 6 | 81673 Munich | District Court
Munich | HRB 290004 | Managing Directors: Bertrand Dissler, Steven D. Barbo,
Jeanne O‘Keefe
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
