While I might expect a different environment not to expose the bug, I am suprised that neither run gave correct results. On my machine, for 24777695232, I get:

1
2
2
2
2
2
2
2
2
2
2
2
2
2
3
7
73
79
# without bug
2
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
461
[download]

Which version of Parei do you have?
$VERSION = '2.010603';

...have you tried moving the call to sqrt after the call to factorint()?
Yes - and it removes the bug - thanks! I was dealing with 3 major versions of my code and minor versions of each (with and without optimizations) and that was 1 of the few things I hadn't tried.

Anyway, trying to get beyond that, I picked a few ideas from tall_man's code (which is definitely the benchmark in this thread) and modified your code to read as:
tall_man's code is impressive, but QM did state that all you start with is the prime factorization. Obviously if some module can give you the factors already you use that solution, so my quest became an academic exercise.

Going by the time your program takes in comparison to tall_man's, you appear to be doing a similar amount of work, but your code is returning -1, which I do not understand?
I am pretty sure this is an overflow issue, but believe it or not these large numbers aren't particularlly difficult. Given QM's original problem - numbers that result in a lot of prime factors would be difficult such as 24777695232. Your first number only has 5 factors which makes the number of combinations to test small:

17
113
5882353
73765755896403138401
119968369144846370226083377
[download]

...which despite being nearly as big a number, is solved in under a 1/5th of a second rather than 17+ seconds above. The very close similarity in timing between your code and tall_man's suggests that you are probably doing a very similar amount of work and possibly arriving at the same result, but for some reason, failing to display it?.
Yeah, doing a binary search on 5 numbers is bound to be faster than generating all the combinations and determining the product, but I still don't get anywhere near the 17+ seconds you see, albeit with an incorrect answer of 7.37657566340607e+27. If you want to benchmark numbers that I know my code can handle, use the following:

#!/usr/bin/perl
use strict;
use warnings;

open(RANDOM, '>', 'random.dat') or die $!;
print RANDOM (int( rand 31415926535 ) + 1), "\n" for 1 .. 50_000;
[download]

Either way, your determination of the appropriate sequence of tests and short-ciruiting is very impressive. I congratulate you++
Thanks. As I said, this became more of an academic exercise. See this for more details. Now that I can make the bug go away, I can test which version is the fastest with all optimizations. Thanks!