[log4perl-devel] SV (Scalar Variable) error in log4perl

[Gil V. <gil...@po...>]

Kevin, We're using log4perl in the Perl Object Environment (POE) running on
Perl 5.8.7 on Red Hat Linux servers. POE is a state machine in a
multi-tasking environment. (see poe.perl.org). Unfortunately, the error is
random, but we are narrowing it down.

I updated to log4perl 1.04 and the problem persists, so I commented out line
217 below (it's line 239 in 1.04). Now my application is dying on "if
(Log::Log4perl::Level::isGreaterOrEqual($level..." with the same
unreferenced SV error as before.

 foreach my $levelname (keys %priority){

        if (Log::Log4perl::Level::isGreaterOrEqual($level,
                                                   $priority{$levelname}
                                                   )) {
            print "  ($priority{$levelname} <= $level)\n"
                  if _INTERNAL_DEBUG;
            $self->{$levelname}      = $coderef;
            $self->{"is_$levelname"} = generate_is_xxx_coderef("1");
            #$self->{"is_$levelname"} = sub { 1 };
        }else{
            print "  ($priority{$levelname} > $level)\n" if _INTERNAL_DEBUG;
            $self->{$levelname}      = $noop;
            $self->{"is_$levelname"} = generate_is_xxx_coderef("0");
            #$self->{"is_$levelname"} = sub { 0 };
        }
=cut
        print("  Setting [$self] $self->{category}.$levelname to ",
              ($self->{$levelname} == $noop ? "NOOP" :
              ("Coderef [$coderef]: " . scalar @appenders . " appenders")),
              "\n") if _INTERNAL_DEBUG;
=cut
    }	


I'm not farmilar with Logger.pm code, but it seems that "sub
set_output_methods" is being called by init_and_watch, so I'm updating all
calls to logger to use the standard init and avoid the "init_and_watch".

#use Log::Log4perl;
Log::Log4perl->init_and_watch('/usr/local/xray/log4perl.conf',600); my $log
= Log::Log4perl->get_logger('Compiler');
use Log::Log4perl; Log::Log4perl->init('/usr/local/xray/log4perl.conf'); my
$log = Log::Log4perl->get_logger('Compiler');

Perhaps the state machine doesn't play well with the dynamic component of
init_and_watch, which obviously has to check to see if a file has changed
every so often. In a sense "init_and_watch" is kind of a state machine that
is triggered by a file change. Since POE is a state machine too, there could
be a clash?

I would appreciate any other suggestions to solve this problem.

Gil...@Po...
Position Research, Inc.
Search engine results by research
tel: (760) 480-8291 fax: (760) 480-8271
www.PositionResearch.com





-----Original Message-----
From: Kevin M. Goess [mailto:ke...@go...] 
Sent: Wednesday, April 12, 2006 9:10 AM
To: Gil Vidals
Cc: log...@li...
Subject: Re: [log4perl-devel] SV (Scalar Variable) error in log4perl

Gil Vidals wrote:
> We have four servers running an application which has incorporated 
> log4perl verion 1.02. We are running into a peculiar error, which 
> crashes our application;
>  
> Attempt to free unreferenced scalar: SV 0x9edad98 at 
> /usr/local/lib/perl5/site_perl/5.8.7/Log/Log4perl/Logger.pm line 217.
> 
> Line 217 from Logger.pm
>  print("  Setting [$self] $self->{category}.$levelname to ",
>               ($self->{$levelname} == $noop ? "NOOP" :
>               ("Coderef [$coderef]: " . scalar @appenders . "
appenders")),
>               "\n") if _INTERNAL_DEBUG;

Gil, this could shouldn't even get compiled, much less run, unless you've
turned _INTERNAL_DEBUG on.  Did you turn it on?  Does the error still happen
if you turn it off?  Does the error still happen if you remove that line of
code?

When you say servers, are you talking about standalone perl applications or
web servers or what?  If they're web servers, are they running with
mod_perl, Catalyst, Mason, or what?  Can you give us more details on the
what this is running in?

What sort of conditions lead to the error? Can you reproduce it at will? 
  Or is it intermittent and seemingly random?

Lastly, but best of all, can you take everything out of the application
except for the absolute minimum amount of code required to produce the
error?  And then could we see the little bit of code that's left?