From: "Martin v. Loewis" <martin@v.loewis.de> > "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov> writes: > > > python -> dlopen ext1.so with statically linked libboost_python.a > > python -> dlopen ext2.so with statically linked libboost_python.a > > That explains a lot of things indeed. It doesn't explain why the > exception handling on Linux fails (that should still work fine even > with two separate copy of each typeinfo object, IMO), Not the way I read http://gcc.gnu.org/faq.html#dso. Am I missing something? If an exception is thrown from ext1 -> ext2 and they're not sharing symbols, there will be distinct copies of all typeinfo objects used in the two modules, and the address comparisons used to determine whether a catch clause matches ought to fail, no? > but it gives a > clue as to what things may have broken: you get two copies of each > global object, and gives you access to both copies. Depending on the > exact interaction sequence, it is well possible that all kinds of > corruption occur. I don't think Ralf is explicitly using any non-const global objects or explicitly relying on on object identity across extension modules, so it's hard to imagine that this is at play. -Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4