Bug #78152 for Date-Manip: Undefined subroutine &Date::Manip::DateManipVersion

Mon Jul 02 14:20:28 2012 perl [...] evancarroll.com - Ticket created

Subject:

Undefined subroutine &Date::Manip::DateManipVersion

Message body is not shown because it is too large.

Mon Jul 02 14:20:53 2012 perl [...] evancarroll.com - Severity Important added

Mon Jul 02 14:20:53 2012 perl [...] evancarroll.com - Broken in 6.32 added

Mon Jul 02 14:32:50 2012 sbeck [...] cpan.org - Correspondence added

I actually see this behavior periodically when I'm working on the module. It happens when I introduce a typo into one of the files that makes it impossible to load it, and that causes the test (which loads Date::Manip to be unable to load it, so it doesn't find the routine). Have you edited any of the .pm files? It would appear to me that the .pm files have been altered somehow (perhaps a corrupted version was downloaded, or perhaps you were experimenting with some local modification) that caused this. I'd blow the module away and try downloading and installing fresh.

Mon Jul 02 14:32:50 2012 The RT System itself - Status changed from 'new' to 'open'

Mon Jul 02 16:22:04 2012 perl [...] evancarroll.com - Correspondence added

This happens because the factory is stupid and a failure in the eval results in a silent murder of the import process -- Evan Carroll System Lord of the Internets http://www.evancarroll.com

Subject:

0001-added-new-verbosity-to-factory.patch

From 26964845e8bf0ef50884812ad8f043143388f730 Mon Sep 17 00:00:00 2001 From: Evan Carroll <me@evancarroll.com> Date: Mon, 2 Jul 2012 15:19:51 -0500 Subject: [PATCH] added new verbosity to factory --- lib/Date/Manip.pm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/Date/Manip.pm b/lib/Date/Manip.pm index 9c6af10..22abbc9 100644 --- a/lib/Date/Manip.pm +++ b/lib/Date/Manip.pm @@ -30,7 +30,8 @@ if ((exists $ENV{'DATE_MANIP'} && $ENV{'DATE_MANIP'} eq 'DM5') || my $backend_exp = $backend . "::EXPORT"; -eval "require $backend; $backend->import(); return 1;"; +eval "require $backend; $backend->import() or die $! return 1;" + or die "ERROR LOADING MODULE $@"; { no strict 'refs'; -- 1.7.9.5

Tue Jul 03 08:59:12 2012 sbeck [...] cpan.org - Correspondence added

I have no problems applying this patch... though shouldn't the line be: eval "require $backend; $backend->import() or die $!; return 1;" (note the added semicolon after the die)? Also, do you have any ideas why the factory eval fails? Is there a safer way to do this that I should be doing instead? Also, I'm not very familiar with the concept of factories. Is there a fairly simple set of steps that I can do to reproduce this? I'd like to understand the failure a bit more. Thanks

Thu Jul 05 17:50:00 2012 perl [...] evancarroll.com - Correspondence added

On Tue Jul 03 07:59:12 2012, SBECK wrote: Show quoted text

> I have no problems applying this patch... though shouldn't the line be: > > eval "require $backend; $backend->import() or die $!; return 1;" > > (note the added semicolon after the die)?

Lol, yes there should be a semicolon there. Though interestingly enough it's not required. Eval doesn't have to succeed. That whole `return 1` is rather silly. Evals return value doesn't matter at all -- only whether or not an exception was thrown. Show quoted text

> Also, I'm not very familiar with the concept of factories. Is there a > fairly simple set of steps that I can do to reproduce this? I'd like to > understand the failure a bit more.

The failure comes from the use statement for YAML::Syck existing ONLY in the class you're requiring and not in the factory. If YAML::Syck isn't installed then the `require` throws an exception. Because the call to require is guarded in an eval though, that exception goes unnoticed. The program then continues to attempt to execute without ever having made it to the $backend->import() (the call to require threw an exception). This problem would only exist if you tried to play with the module without running the dependency-check on the Makefile.PL -- that was my own mistake. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com

Fri Jul 06 09:05:39 2012 sbeck [...] cpan.org - Correspondence added

So I applied it, and now, everything fails with the error: ERROR LOADING MODULE The import() method does not have a return value (it's null whether the import fails or succeeds) which means (in the case of your patch) that the 'die' statement is always called, so the eval fails, and you get the error message. Obviously I can't apply the patch as is. If you'd like to submit an alternate one, I'll be happy to look at it.

Fri Jul 06 09:10:36 2012 sbeck [...] cpan.org - Correspondence added

What about the following: my $flag = eval "require $backend; $backend->import(); return 'loaded';"; if (! $flag) { die "ERROR LOADING MODULE"; } That works (if the import fails, the eval exits, and $flag is set to nothing.

Tue Jul 17 09:46:14 2012 sbeck [...] cpan.org - Correspondence added

I've added the lines that I suggested. Let me know if you experience any problems.

Tue Jul 17 09:46:15 2012 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'