Bug #41060 for ExtUtils-MakeMaker: Warning: Can't call method "isa" without a package or object reference

Wed Nov 19 07:12:41 2008 REHSACK [...] cpan.org - Ticket created

Subject:

Warning: Can't call method "isa" without a package or object reference

Hi, when I updated to perl 5.10 and ExtUtils::MakeMaker 6.48 I got following error when invoking perl Makefile.PL: ------------------------------------------------------------ unhandled exception caught: Can't call method "isa" without a package or object reference @/opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm:125 00 BDClog::uncaughtException /opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm: 125 01 (eval) /opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm: 125 02 ExtUtils::MakeMaker::_verify_att /opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm: 55 03 ExtUtils::MakeMaker::WriteMakefile Makefile.PL : 163 ------------------------------------------------------------ imyir@uf6e Makefile.PL/745588 [#notice(core)]: unhandled exception caught: Can't call method "isa" without a package or object reference @/opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm:125 Checking if your kit is complete... Looks good Writing Makefile for ... I modified line 125 and using UNIVERSAL::isa($val,$_) instead of $val->isa($_)

Mon Dec 01 16:18:19 2008 REHSACK [...] cpan.org - Correspondence added

Patch attached

Download patch-ad
application/octet-stream 790b

Message body not shown because it is not plain text.

Mon Dec 01 16:18:23 2008 REHSACK [...] cpan.org - Status changed from 'new' to 'open'

Thu Feb 19 19:42:20 2009 mschwern [...] cpan.org - Correspondence added

On Wed Nov 19 07:12:41 2008, REHSACK wrote: Show quoted text

> when I updated to perl 5.10 and ExtUtils::MakeMaker 6.48 I got following > error when invoking perl Makefile.PL: > > ------------------------------------------------------------ > unhandled exception caught: Can't call method "isa" without a package or > object reference > @/opt/pkgsrc/lib/perl5/vendor_perl/5.10.0/ExtUtils/MakeMaker.pm:125 > 00 BDClog::uncaughtException

I would need to see your Makefile.PL to diagnose this problem, but I suspect that what's really doing on in your logging widget wrapping around the Makefile.PL is being overzealous and catching exceptions which are already inside evals! For example. $ perl -wle '$SIG{__DIE__} = sub { print "Oh no, an exception! $@" }; eval { die "Perfectly normal" };' Oh no, an exception! You need to check $^S. Also your patch was for something else entirely.

Thu Feb 19 19:42:25 2009 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Tue Jun 02 03:08:45 2009 REHSACK [...] cpan.org - Correspondence added

The Makefile.PL I created in the project which caused the problem may be not the best, but you are using $val without proving if it's defined. You may find another solution for the problem, but it remains and regardless of the waste in my Makefile.PL :)

Tue Jun 02 03:08:46 2009 The RT System itself - Status changed from 'stalled' to 'open'

Tue Jun 02 14:29:16 2009 mschwern [...] cpan.org - Correspondence added

On Tue Jun 02 03:08:45 2009, REHSACK wrote: Show quoted text

> The Makefile.PL I created in the project which caused the problem may be > not the best, but you are using $val without proving if it's defined. > You may find another solution for the problem, but it remains and > regardless of the waste in my Makefile.PL :)

It's *INSIDE AN EVAL* and the whole point is for it to fail to detect a non-object. It should not matter unless someone installed an impolite global $SIG{__DIE__}. This is going to trip up every eval in MakeMaker and every other module that might be used. It's not a "waste", nor is it unique to MakeMaker. If you do it, things will break. It's a shame that $SIG{__DIE__} doesn't ignore eval's by default, but that's the way it is. Using UNIVERSAL::isa() as as function is bad form. An object is well within its rights to override isa(). That just replaces one problem with another. Now that I've vented, I'll admit that code is kinda squished and has been a bit of a thorn. I've refactored it into its own function and tested it. As long as I was there it now protects itself against an errant $SIG{__DIE__}. See 328f6af on github.

Tue Jun 02 14:29:18 2009 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Jun 02 18:36:25 2009 rehsack [...] web.de - Correspondence added

Subject:	Re: [rt.cpan.org #41060] Warning: Can't call method "isa" without a package or object reference
Date:	Tue, 02 Jun 2009 22:27:01 +0000
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Jens Rehsack <rehsack [...] web.de>

Michael G Schwern via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=41060 > > > On Tue Jun 02 03:08:45 2009, REHSACK wrote:

>> The Makefile.PL I created in the project which caused the problem may be >> not the best, but you are using $val without proving if it's defined. >> You may find another solution for the problem, but it remains and >> regardless of the waste in my Makefile.PL :)

> > It's *INSIDE AN EVAL* and the whole point is for it to fail to detect a > non-object. It should not matter unless someone installed an impolite > global $SIG{__DIE__}.

I don't know why it's impolite to track uncaught exception. Because, eval is the only way to avoid immediately abort, such a handler must always analyze the stack where the eval appears which costs performance. It's becoming more and more common to have a global die-handler which reports uncaught exceptions to report about possible problems. I'm just a messenger this time - I just see this at a customer (and similar behavior in other projects). Show quoted text

> This is going to trip up every eval in MakeMaker > and every other module that might be used. It's not a "waste", nor is > it unique to MakeMaker. If you do it, things will break. It's a shame > that $SIG{__DIE__} doesn't ignore eval's by default, but that's the way > it is.

You mean, that eval doesn't imply "local $SIG{__DIE__} = '';" I agree, that it would be better - maybe this is accepted as a proposal for future perl releases? Show quoted text

> Using UNIVERSAL::isa() as as function is bad form. An object is well > within its rights to override isa(). That just replaces one problem > with another.

That's right. Show quoted text

> Now that I've vented, I'll admit that code is kinda squished and has > been a bit of a thorn. I've refactored it into its own function and > tested it. As long as I was there it now protects itself against an > errant $SIG{__DIE__}. See 328f6af on github.

Thanks, Jens

Tue Jun 02 18:36:26 2009 The RT System itself - Status changed from 'resolved' to 'open'

Tue Jun 02 19:08:32 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #41060] Warning: Can't call method "isa" without a package or object reference
Date:	Tue, 02 Jun 2009 16:08:11 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

rehsack@web.de via RT wrote: Show quoted text

>> On Tue Jun 02 03:08:45 2009, REHSACK wrote:

>>> The Makefile.PL I created in the project which caused the problem may be >>> not the best, but you are using $val without proving if it's defined. >>> You may find another solution for the problem, but it remains and >>> regardless of the waste in my Makefile.PL :)

>> It's *INSIDE AN EVAL* and the whole point is for it to fail to detect a >> non-object. It should not matter unless someone installed an impolite >> global $SIG{__DIE__}.

> > I don't know why it's impolite to track uncaught exception.

It's not. But in this case -->>the exception was caught<<-- that's why it was IN AN EVAL IN THE FIRST PLACE! The problem with a naive global $SIG{__DIE__} handler is it trips on *caught* exceptions. Show quoted text

> Because, eval is > the only way to avoid immediately abort, such a handler must always analyze > the stack where the eval appears which costs performance.

This is what $^S is for. I don't expect most folks to know about $^S but this is the second time I've mentioned it. $SIG{__DIE__} = sub { return if $^S; ...your exception handling code... }; Show quoted text

> It's becoming more > and more common to have a global die-handler which reports uncaught > exceptions to report about possible problems. I'm just a messenger this time > - I just see this at a customer (and similar behavior in other projects).

With great power comes great responsibility. If you want to install a global exception handler (or a global ANYTHING handler) you have to know how to do it right. Show quoted text

>> This is going to trip up every eval in MakeMaker >> and every other module that might be used. It's not a "waste", nor is >> it unique to MakeMaker. If you do it, things will break. It's a shame >> that $SIG{__DIE__} doesn't ignore eval's by default, but that's the way >> it is.

> > You mean, that eval doesn't imply "local $SIG{__DIE__} = '';" > I agree, that it would be better - maybe this is accepted as a proposal for > future perl releases?

The fact that it doesn't is considered a misfeature, but it would break backwards compatibility severely to change it at this point. It would either have to go through a full deprecation cycle or be a "use 5.012" conditional. -- 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett

Wed Jun 03 05:10:25 2009 rehsack [...] web.de - Correspondence added

Subject:	Re: [rt.cpan.org #41060] Warning: Can't call method "isa" without a package or object reference
Date:	Wed, 03 Jun 2009 09:01:01 +0000
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Jens Rehsack <rehsack [...] web.de>

Michael G Schwern via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=41060 > > > rehsack@web.de via RT wrote:

>>> On Tue Jun 02 03:08:45 2009, REHSACK wrote:

>>>> The Makefile.PL I created in the project which caused the problem may be >>>> not the best, but you are using $val without proving if it's defined. >>>> You may find another solution for the problem, but it remains and >>>> regardless of the waste in my Makefile.PL :)

>>> It's *INSIDE AN EVAL* and the whole point is for it to fail to detect a >>> non-object. It should not matter unless someone installed an impolite >>> global $SIG{__DIE__}.

>> I don't know why it's impolite to track uncaught exception.

> > It's not. But in this case -->>the exception was caught<<-- that's why it was > IN AN EVAL IN THE FIRST PLACE! > > The problem with a naive global $SIG{__DIE__} handler is it trips on *caught* > exceptions.

This customer (others have similar) has following code (example!): (global scope): $SIG{__DIE__} = \&warn_uncaught_exceptions; ... sub try { local $SIG{__DIE__}; eval { $_[0] }; do { catch | throw ... } if($@); } If there comes another eval {} block, it'll doesn't override the global $SIG{__DIE__}. Show quoted text

>> Because, eval is >> the only way to avoid immediately abort, such a handler must always analyze >> the stack where the eval appears which costs performance.

> > This is what $^S is for. I don't expect most folks to know about $^S but this > is the second time I've mentioned it. > > $SIG{__DIE__} = sub { > return if $^S; > > ...your exception handling code... > };

Good point. I'll "forward" this suggestion. Show quoted text

>> It's becoming more >> and more common to have a global die-handler which reports uncaught >> exceptions to report about possible problems. I'm just a messenger this time >> - I just see this at a customer (and similar behavior in other projects).

> > With great power comes great responsibility. If you want to install a global > exception handler (or a global ANYTHING handler) you have to know how to do it > right.

In that case the global exception handler was installed to trap even such eval {require foo;} - because some of the machines weren't properly installed and this was used to detect errors (in all packages). Finally - you're right. But it's a bit more difficult and except this RT all other issues were solved in past. Show quoted text

> The fact that it doesn't is considered a misfeature, but it would break > backwards compatibility severely to change it at this point. It would either > have to go through a full deprecation cycle or be a "use 5.012" conditional.

Sure, but 'use 5.010' enables all new features of perl 5.10. And it should be possible to code: 'use 5.010 if($^V >= 5.010);' Jens

Sat Jun 06 01:33:17 2009 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'