in reply to Attempt to free unreferenced scalar: (or how I learnt to stop worrying and love @INC)

This may very well be a bug. Either in Perl, or in some module. Your @INC suggests that binary modules are picked from either the 5.8.3 core libs, or from either the 5.8.3 or 5.8.0 site libs. Since 5.8.3 is supposed to be binary compatible with 5.8.0, this should be OK.

So, either 5.8.3 isn't binary compatible, or there's a module somewhere that has a binary compatibality issue, but installed itself in a non-binary directory.

Too bad you didn't figure out which module was causing the problem.

Abigail

  • Comment on Re: Attempt to free unreferenced scalar: (or how I learnt to stop worrying and love @INC)

Replies are listed 'Best First'.
Re:x2 Attempt to free unreferenced scalar: (or how I learnt to stop worrying and love @INC)
by grinder (Bishop) on Jan 23, 2004 at 15:07 UTC

    Hmm, I didn't consider it was a bug in Perl, I assumed it was my fault. Also, it's the first time I've come across such a problem, so I wasn't sure of the steps to take. I'll know better next time.

    I actually thought I would have to live with the @INC hack until such time as I could clean up my installation. By chance I deleted the BEGIN block and noticed that it worked anyway.

    For what it's worth, this is the list of modules I reinstalled (in order of appearance):

    • DBI
    • DBD::Pg
    • NetAddr::IP
    • Parallel::ForkManager

    I think the problem module is Parallel::ForkManager. CPAN reported it as being up to date, and yet the program continued to emit "Attempt to free" messages. I did a force install and the problem cleared up after that.

    But then P::FM appears to be a pure Perl module. Only DBI and DBD::Pg contain XS code (which is what I would expect to cause the problem), and, apart from action-at-a-distance, I don't see what they have to do with the problem of the IO::Socket::INET constructor. Still, stranger things have happened.

[reply]
Re: Re: Attempt to free unreferenced scalar: (or how I learnt to stop worrying and love @INC)
by Mr. Muskrat (Canon) on Jan 24, 2004 at 02:39 UTC
    Perhaps the modules that were installed for 5.8.3 were not installed for 5.8.0. If that is the case then it is not a bug. His @INC included 5.6.1 and 5.005 and those are definitely not binary compatible with 5.8.x.
[reply]

      His @INC included 5.6.1 and 5.005 and those are definitely not binary compatible with 5.8.x.

      ...but his @INC did not include the arch dirs for 5.6.1 & 5.005. I've had this problem as well, in fact I posted it to the dbi-users list. Nothing was resolved. I've had this happen on FreeBSD, OSF and Linux. I was upgrading the Perl on these servers to 5.8.1. I have a CPAN script that installs the modules we use and it would "hang" when installing Bundle::DBI. On the OSF it actually used all the swap space up. I finally was able to resolve this by moving the */site_perl/5.6.1 to a temp name and installed all the modules in the 5.8.1 tree. Everything I've read indicates that 5.8.x is supposed to only look for the Perl only modules and not use the old XS compiled modules. Maybe there is a XS compiled module in a non-standard dir. The only way I've been able to upgrade is to rename the site_perl/5.6.1 dir. I'm glad someone else has had this problem, I thought I was the only one. I have another server that needs to be upgraded, so I am going to install everything manually and see if can figure out why this is happening.

      sth

[reply]

In Section Meditations