Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

(in cleanup)

by narse (Pilgrim)
on Sep 04, 2003 at 20:35 UTC ( [id://289014]=perlquestion: print w/replies, xml ) Need Help??

narse has asked for the wisdom of the Perl Monks concerning the following question:

I am experiencing a bug that I find difficult to explain.
(in cleanup) Not a reference to a Digest::MD5 object at /export/home/n +arse/cvs/plord/lib/Games/LORD/Locations/Helper/Menu.pm line 422.
I have an object (Player.pm) that uses Digest::MD5 to encrypt passwords before they are stored in a database. This is the ONLY module that uses Digest::MD5. This non-fatal warning is triggered at some points where this object is passed around in a hash as a method parameter. Menu.pm, line 422 looks like this:
if ( not defined $input or $input eq "" ) { return $hidden_actions{ DEFAULT } -> ( %args ) }
where %args contains the Digest::MD5 using Player object.

This bug is not exclusive to this location, it seems to occur at various points where similar parameter passing takes place. One notable point is:
delete $data -> {opponent};
where $data -> {opponent} is another such Player object. I do not believe the bug occurs until after this point. After this, all Player objects appear to be affected by this bug. $data -> {opponent} is never again used after this point so it is not a simple issue of undefined values.

Digest::MD5 has both an OOP and Exporter use and I have tried both with no change in operation. Is this a bug with Digest::MD5? Am I somehow breaking its namespace by using delete on my own bless object?

Replies are listed 'Best First'.
Re: (in cleanup)
by pzbagel (Chaplain) on Sep 04, 2003 at 21:57 UTC

    Sounds like your delete routine is destroying the Digest::MD5 object which is being pointed to from other objects. Are you ensuring that each Player object gets its own instance of Digest::MD5->new?

      I should add that the work Digest::MD5 does continues to be done. None of the functionality is lost, the only change is the warning message. I also noted that I have tried both the OOP and Exporter methods of Digest::MD5. Currently, I am using Exporter so..
      use Digest::MD5 qw/md5_hex/;
      Digest::MD5 -> new() is not a part of the code.
Re: (in cleanup) (d'tor order)
by tye (Sage) on Sep 05, 2003 at 04:55 UTC

    Once Perl is done destroying any lexicals, it stops trying to be well-ordered and instead goes for speed and deletes all remaining objects in some order that it finds fast.

    This means that if you have an object that survives that long and that depends on another object, then you are likely to see those objects destroyed in the wrong order. This only happens during "global destruction".

    So if you can avoid having objects in global variables, referenced (even indirectly) from global variables, or used in closures (though newer versions of Perl probably destroy some closures sooner -- I haven't checked) then you can avoid this problem.

    I'm glad you found a solution to the problem, but I wanted to explain the source of it.

                    - tye
Re: (in cleanup)
by narse (Pilgrim) on Sep 04, 2003 at 23:06 UTC
    I replaced Digest::MD5 with Digest::SHA1 which is probably a better choice for passwords anyhow. The problem went away. There must be a bug in Digest::MD5...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://289014]
Approved by Mr. Muskrat
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-04-18 19:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found