Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

phillup (4419)

  (email not shown publicly)

Journal of phillup (4419)

Friday November 12, 2004
12:48 PM

Garbage Collection Strangeness

Here is a minimal script that demonstrates (on my system) the strange behavior I am experiencing.

If I uncomment the undef statement, then everything seems to work. But, if I let Perl take out the garbage it looks like my CGI::Session object gets destroyed before my own session object is destroyed. Even tho I still have a reference to the object. (Actually, my reference goes away!)

I can work around the problem by making sure I trigger the object destruction myself. But, I'd really like to know if the problem is in my mental picture of how things are supposed to work.

UPDATE: It appears to be my mental picture. ;-)

Apparently global garbage destruction is somewhat random in order. So, make sure you take out your own garbage if the order is important!

Any comments greatly appreciated!


#! /usr/bin/perl
use strict;
use warnings;
my $session = new My::Session;
sub skipme{
  my $test = $session->{test}; # no I don't normally access the object data directly
                               # I just need to use the object in the sub to trigger
                               # the problem and I want to reduce the number of methods
                               # to the bare minimum to demonstrate the problem
} # sub skipme
print "\nDone\n";
#undef $session;
  package My::Session;
  use strict;
  use warnings;
  my $session_dir = '/tmp/cgisession/';
  use CGI::Session::File;
  sub new{
    # get our class of object
    my $CLASS = shift;
    my $SELF = {};
    # get a new storage session
    $SELF->{session} = new CGI::Session("driver:File;serializer:FreezeThaw", undef, {Directory => $session_dir})
      || die 'Could not get new session store!';
    # and bless ourself
    bless $SELF, $CLASS;
    return $SELF;
  } # sub new
  sub DESTROY {
    my $SELF = shift;
    print "Hey!! Someone stole my session!\n" unless $SELF->{session};
  } # sub DESTROY

Thursday November 11, 2004
04:16 PM

Unexpected behavior

I'm experiencing behavior that was not expected, and I'm wondering if this is "normal".

I have a "session" object that has a "has a" relationship with CGI::Session.

If I make sure to undef my object before the program ends, then everything is fine.

However, if I don't specifically undef my session object... and instead rely on the default garbage collection... it looks like the CGI::Session object I'm using gets destroyed BEFORE my session object gets destroyed.

It would seem to me that there should still be a reference count to the CGI::Session object as long as my object exists and that my session object would be destroyed first. Isn't this the way it is supposed to happen?

I managed to squeak out a diagnostic message that said

DESTROY created new reference to dead object

and have litterd my code with diagnostic print statements. Everything is fine until I make a call to the CGI::Session's param method and then the program spits out:

Can't call method "param" on an undefined value...

I am about to write a "minimal" object to try and replicate (and hopefully fix) the problem. But, I was wondering if I'm just totally mixed up on Perl's garbage collection.



UPDATE: By adding a print statement to my destructor and the destructor in CGI::Session I can definitely say that CGI::Session is being destroyed before my object is.


UPDATE 2: I've posted code that demonstrates the problem in a new journal entry.

Friday November 05, 2004
11:00 AM

Political Results

I saw this picture which was linked to from a slashdot article.

I'm sure it is all about point of view, but... it looks to me like small signs of civilization in a vast waste land.

Tho, I do think the picture is "rigged". The color used to indicate the republican votes does not show relief very well. At first glance the "red" vote looks pretty flat. You have to look really hard to see the *shadows* from the raised levels.

If you look at the shadows (for both red and blue) you start to notice something very strange... they are all on the "eye" side! So, looking west you see the shadow side of the raised features... and, looking east also shows you the shadow side.

That is not right.

Tuesday September 28, 2004
06:19 PM

How do you install modules?

I was just reading a post by rafael and it got me thinking about something that I've been wondering about a for a long time.

Mainly, installing Perl modules from a vendor vs. installing via CPAN.

For myself, I usually install almost everything via CPAN... because they don't get updated during normal system updates. That way I've got a chance to run updates on a dev server (and my test scripts) before they make it into production.

In some cases I actually recompile a custom Apache and (mod)Perl specifically so that system updates don't fubar what I've written. (OSX is one such case. The vendor version(s) don't like Mason that well. Panther is better, but I've had problems that were resolved by compiling custom versions.)

Now, one obvious downside is when there might be a serious data damaging (or security) issue... and I haven't kept things up to date.

So... how do others handle module installs? Do you do everything one way... like always use the vendor version unless there isn't one.... a mixture, like installing everthing that requires a compiler using the vendor modules and the rest from CPAN... or is it less "planned" than that?


Friday September 10, 2004
07:12 PM

Just Me?

Is it just me, or:

1) Did slashdot get a bit slower since putting in the politics section?


2) Was anyone else a bit less productive this week?

Friday August 13, 2004
01:29 PM

cheap profiler

Well, there was an interesting side effect of parsing my web logs to identify all the places where I'm throwing warnings.

I've got a relative count of how many times the code is being called. Of course, it is only the code that causes warnings that is being counted...

Anyways, this is my most troublesome snippet, accounting for 80 percent of the current warnings.

  $form .= $args->{'hidden'};
  $form .= '</form>';

This code builds forms, and has an optional parameter for hidden fields. If there are any hidden fields, they are added right before we close off the form.

It seems a bit much to have to say

  $form .= $args->{'hidden'} if $args->{'hidden'};

When the original code "Does The Right Thing".

Also, 100% of the errors have to do with string concatenation, or comparison operators where I expect that values may be 'undef'.

So... I'm about to spend a lot of time eleminating warnings that are "harmless". Because, even with all my bitching... I know that there will be a payoff... eventually.

12:52 PM

Interesting reaction

I'm a lurker. There, I've said it. I watch, I listen (or read, as the case may be) and, on the really good days... I learn. I read a post by Randall and went to have a look for myself. I'm not sure what it will look like later, hopefully it will change. But, right now there are big black boxes where all of the code is. You can, of course, hilite the code with your cursor and read every thing. But, this reaction... the blocking out of the code, is really disturbing to me for several reasons.
  • The nature of "open source" is that code be available. Technically, it still is. But, an effort has been conciously made to make this code less so. I'm not sure what bothers me more... that it was done in the first place, or done so inneffectively. (After reading the node again, it seems that the individuals are blacking out their own code, if they wish. That isn't *quite* as disturbing...)
  • It is a community site. The nature of the community is one of the things I like about Perl. It isn't just a language. That nature, for the most part is one of openness and sharing. Yet, this doesn't seem to be very open like.

I've read in Perl Medic that to reach the highest level you will need to take part in "Perl obfuscation"... I sincerely hope this doesn't qualify.

10:37 AM

Dreaming about warnings

Andy just posted that he dreams about Perl people.

Last night I dreampt about Andy, or... more specifically, about what he wrote.

I've had my head buried in the (formal) tests for a bit now. Trying desperately to catch up and put some automated testing in place for code I've been writing for two years. It is a lot of code and writing (legitimate) tests for all of it is going to be huge.

That's the price of sin I guess...

Anyways... I took his comment to be talking about my tests. It dawned on me during the night that I have warnings in my web server logs...

Andy said: Do NOT ignore warnings.

I heard: Do NOT ignore warnings in your tests.

I'm not sure if that is what he meant. Probably not.

Either way, the nugget of knowledge is: Do NOT ignore warnings. But, I've been doing just that... ignoring the warnings in the web logs.

So, today I will be spending some time looking thru the server logs and trapping warnings.

I'm a bit slow at times, but I like to think I can still learn a trick or two.

Thanks Andy!

Thursday August 12, 2004
06:40 PM

Perl Stumblings

While googling for some info on hashes in scalar context I stumbled upon this page.

Playing with the URL a bit got me here.

And clicking on the last link got me this page which I immediately bookmarked.

06:25 PM

Warning Will Robinson

So, about a month ago I got all into writing test code for my modules. But, we are talking a *LOT* of code... so, I'm spending an hour or so a day to write tests of the existing code... and the rest of the day I write tests before writing new code.

I figure I'll get caught up an a year or two.


Anyways... one of the test that I wrote checked each module file (and all of my maintenance scripts) for 'use warnings'.

So, it took a day to fix all of the files and the warnings... proof positive of the need for unit testing.

Still, since I'm starting so late in the process and taking a 'piecemeal' approach to getting full test coverage (that'll be the day!)... I'm coming across many places where I get a particular warning:

Use of uninitialized value in...

Now, one hundred percent of the time (so far) that I have gotten the warning, my code has been "reasonable". In other words... there were not any "unintentional" use of the variables. For example:

my $sum;
foreach (keys %scores){
  $sum += $scores{$_};

Will trigger the warning, since I'm using sum without explicitly setting the value to zero before hand. But, this is Perl, and I know that it will do that for me. And... I'm lazy. Worse, I don't see the need to do it twice (once by Perl, once by me).

And, since I believe that any variable that is lexically scoped via 'my' should be considered initialized... that is just salt in the wound to me.

So... I've been wrapping those small chunks in their own blocks and doing the 'no warnings "uninitialized"' thing... But... I'm leaning towards simply making that the default for the entire module(s).

Are there any warnings that you or your company ignore as "standard practice"?

And, of course, what are the pitfalls of doing so...