[Lazarus] Log4D weirdness

Marco van de Voort marcov at stack.nl
Sat Dec 27 22:49:01 CET 2014


On Fri, Dec 19, 2014 at 06:49:07PM -0300, Mario R. Carro wrote:
> There's a LogLog variable that is destroyed in the finalization section 
> (and fails). The problem is that the TLogODSAppender created in the ctor 
> ends up destroyed inside the AddAppender call. This is the AddAppender code:
> 
> procedure TLogLogger.AddAppender(const Appender: ILogAppender);
> begin
>    LockLogger;
>    try
>      if FAppenders.IndexOf(Appender) = -1 then
>      begin
>        FAppenders.Add(Appender);
>        if FHierarchy <> nil then
>          FHierarchy.FireAppenderEvent(True, Self, Appender);
>      end;
>    finally
>      UnlockLogger;
>    end;
> end;

Yes, this is a known kind of buggy code. (buildin assumptions of Delphi code
that only "happens" to work on Delphi). Delphi /usually/ destroys
automatically created temps at
the end of a function, while FPC can also do it after a block.

Best is to explicitely keep a local variable reference, local variable
references are kept to the end at the moment, as you already found out.

> Who is at fault here? Log4D? The compiler? Me?

Hard to say, there is some opinion involved there.

Like many cases, Delphi does not specify this behaviour, and in general for
Delphi not much is known what of the implementation is intended, or what is
coincidence.  This is aggrevated by the fact that too much Delphi code
messing with interface refcounting seems to be created with trial and error.

However it has come up a zillion times in the bugtracker, and FPC compiler
devels have stated that they won't fix it (since it could inhibit/complicate
implementing certain optimizations in the future), and the code is shoddy to
start with.

Best is to root out these kinds of bugs in the relevant projects (in this
case Log4D)





More information about the Lazarus mailing list