in reply to Bug in Math::Pari ?

From the other comments above, it sounds like you'll need to track down the problem yourself. By the sounds of it you have full control of the box, and can mess with the installed modules safely; if not you'll want to install local copies of the modules before you do so.

The error message is coming from Math::Pari::can:

sub can {
  my ($obj, $meth) = (@_);
  my $f = $obj->SUPER::can($meth);
  return $f if defined $f;
  # There is no "usual" way to get the function; try loadPari()
  $f = eval { loadPari($meth) };   # Math/Pari.pm line 1136
  return $f if defined $f;
  return;
}

[download]

Since that isn't dying itself, clearly some caller is dying with this eval's $@ upon getting a failure returned.

I'd suggest the first thing you need to do is find out the full context in which that's happening, and that's easiest done by putting diagnostics in where you know the problem is occurring:

   $f = eval { loadPari($meth) };
   return $f if defined $f;
+  if ($meth eq 'as_number') {
+    require Carp;
+    Carp::cluck("failed to find as_number");
+  }
   return;
 }

[download]

For this sort of debugging, I tend to keep the vi session open for any module I change, so that I can easily restore the integrity of the modules by (u)ndoing all edits and re-saving. An alternative approach is to copy each module to a .orig file before editing.

Once you have the full stack trace, you can start the debugging proper.

Hope this helps,

Hugo

Replies are listed 'Best First'.
Re^2: Bug in Math::Pari ?
by unlox775 (Initiate) on Nov 25, 2009 at 23:30 UTC
    BTW, I'm still seeing this... I'm trying to get Net::SFTP working, which is calling Net::SSH::Perl which is using Math::BigInt which is using Math::Pari. Here is the whole caller trace (caught using a $SIG{__DIE__}): 
              '__ANON__ called at Math/Pari.pm line 1148',
          '(eval) called at Math/Pari.pm line 1148',
          'can called at Math/BigInt.pm line 2559',
          'objectify called at Math/BigInt.pm line 1757',
          'bmod called at Math/BigInt.pm line 114',
          '__ANON__ called at Net/SSH/Perl/Util/SSH2MP.pm line 28',
          'mp2bin called at Net/SSH/Perl/Buffer.pm line 173',
          '_put_mp_int_ssh2 called at Net/SSH/Perl/Buffer.pm line 138'
+,
          'put_mp_int called at Net/SSH/Perl/Kex.pm line 179',
          'derive_key called at Net/SSH/Perl/Kex.pm line 163',
          'derive_keys called at Net/SSH/Perl/Kex/DH1.pm line 76',
          'exchange called at Net/SSH/Perl/Kex.pm line 100',
          'exchange called at Net/SSH/Perl/SSH2.pm line 92',
          '_login called at Net/SSH/Perl/SSH2.pm line 69',
          'login called at Net/SFTP.pm line 62',
          'init called at Net/SFTP.pm line 24',
          'new called at -e line 1'

    [download]
    Yes, the line it is dying on is this one: 
    sub can {
  my ($obj, $meth) = (@_);
  my $f = $obj->SUPER::can($meth);
  return $f if defined $f;
  # There is no "usual" way to get the function; try loadPari()
  $f = eval { loadPari($meth) }; # <-- THIS LINE
  return $f if defined $f;
  return;
}

    [download]
    So, I'm guessing it's when the loadPari function is getting called. This function must be defined in the Dynaloader (Pari.bs or Pari.so files). I know Perl ok, but when it hits this compiled stuff I don't know how to proceed. By deduction I assume it's trying to load some C-defined function that isn't present. Now, the as_number() function has been defined in the Math::BigInt since v1.22 (2001-04-05), so I think it's not likely that it's just a newly added function and I don't have the newest function... So I'm thinking I don't have another lib that these .so and .bs files need? libpari? I'll keep looking. (And BTW, you guys were unduely harsh to this guy who seems to have been doing his best to learn... "call to the closest available guru" sheesh...)
[reply]
[d/l]
[select]
[reply]

      I wonder if $SIG{__DIE__} is exactly the problem here: the line in Math::BigInt::objectify() is:

      $k->can('as_number') ? $k = $k->as_number : $k = $a[0]->new($k);

      Now, there is a precedence error here (I've reported that), but if can() returns false it shouldn't affect us, it should simply call $a[0]->new($k).

      The code from Math::Pari::can() is:

      $f = eval { loadPari($meth) };
return $f if defined $f;
return;

      [download]

      .. which should correctly return undef if the loadPari() fails. However if some $SIG{__DIE__} is catching the loadPari() failure, maybe we're never getting to return from the eval. Or maybe the die handler is (inappropriately) reporting the error and the code is then successfully continuing.

      I'd be tempted for starters to put a diagnostic in objectify() just after that line, to see if a) it reaches there, and b) $k has the correct value. I'd also hunt for a $SIG{__DIE__} handler, to check what exactly it is doing - generally, such handlers should almost always act only after checking they are not inside an eval. There may be a better way, but when I needed this some time ago for a logging module the code looked like this:

      $SIG{__DIE__} = sub {
  # propagate the die if we're under an eval
  (defined($^S) && !$^S) or die(@_);
  # now do the real stuff
  ...
};

      [download]

      .. but there may be a better way.

      Hugo

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom