This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Global variable in static library - double free or corruption error
On Thu, Oct 21, 2010 at 1:37 PM, Andrew Haley <aph@redhat.com> 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.
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. 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]. In the Microsoft world, if you want to
take the bull by the horns, you have to go out of your way to get it -
it is not default behavior [2].
(And I know M$ is not a stellar example of security).
Making a bad choice (ie, 'the rule') and documenting it does not make
it all OK. Its not reasonably expected behavior, and it might have
security implications.
Jeffrey Walton
[1] Howard and LeBlac, Writing Secure Code, ISBN 0-7356-1722-8, p. 677-78
[2] How do I share data in my DLL with an application or with other
DLLs?, http://msdn.microsoft.com/en-us/library/h90dkhs0%28VS.80%29.aspx