On 10/21/2010 09:21 PM, Jeffrey Walton wrote: > On Thu, Oct 21, 2010 at 1:37 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: >> On 10/21/2010 05:23 PM, Jeffrey Walton wrote: >>>> that there can only ever be one definition of a symbol in a program, >>>> and UNIX has always merged multiple definitions to achieve this >>> Does the rule include that gloabl object destructors are to run on >>> every unload, or the last/final unload or last call to dlclose (when >>> the shared object gets unmapped)? >> >> I suspect that Bad Things would happen. :-) >> >> As far as I know, they are run, and if you have two definitions >> of some object with a destructor, then you violate the ODR rule, >> and it's all your fault! > > When I look at the original source files, it is clear that there is > one definition. I'm not sure what is getting lost in the translation, > but the runtime link-loader 'multiplying definitions' which lead to a > crash is not desired behavior. I would claim it is a bug. Possibly. Can you make a small test case? > Since what happens in one module crashes another module, I would go > out on a limb and claim this bug might have security implications. > >>> Many folks don't expect their objects will be pulled out from >>> under them until the last unload. It seems like a reasonable >>> expectation to me. >> Sure, but you break the rules, you get to keep all the pieces. > I think the problem here is that the rule is f**k'd up. Could well be, but it's rather late to change it now. > I would argue that many folks probably know about the rule. But how > many know about it because they got bit in the ass by it versus > RTFM'ing the manual in their spare time? > > In essence, the rule creates "Shared (Global) Data Segments" in the > Microsoft world. Those things are quite dangerous (because one > process can cause another to crash) and code cannot pass a security > related quality gates if present [1]. This is not true. One process cannot cause another to crash: each has its own memory space. Andrew.
