Dear Mr. Smith,
Thank you for such a swift reply. My boss was running "perl 5, version
22 subversion 1 (v.5.22.1) built for MSWin32-x86-multi-thread-64int."
I suddenly realize that this must be a 32-bit build with 64-bit
INTEGERS, rather than a 64-bit build (I just saw the 64 and jumped to
the wrong conclusion). I asked my boss to run perl -V and give me the
output, which I shall attach.
(And he just found the MSI file, which was, sure enough, called
strawberry-perl-5.22.1.3-32bit.msi.)
I showed him the correct installation program, and will leave him to
uninstall and reinstall.
I still don't think a SEG signal should be raised, particularly in a
32-bit version that *IS* compiled for 64-bit integers, but if the
problem is that he installed the wrong version of Perl, then he should
fix that anyway, and it certainly makes the bug seem less critical.
And, as I said in the initial e-mail, it worked just fine on MY 32-bit
Windoze XP.
I have not yet replaced the module on the 64-bit CentOS system with the
LATEST version of Time::Piece, to verify that the bug is only in the
older version istalled on THAT machine.
I thank you again for responding so very quickly to our report! For me,
the case is closed, and I leave you to fix the SEG fault you were able
to reproduce, if you think that version of the module for perl for
Windoze-32 should behave better when it runs on a 64-bit Windoze 7.
Please do not hesitate to contact me if you need any further
information.
Very truly yours,
Robert S. Kissel
intraLOGICS, L.L.C.
On 2016-04-06 22:34, Samuel Smith via RT wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=113591 >
>
> On 04/06/2016 07:23 PM, rsk@intralogics.net via RT wrote:
>> Wed Apr 06 20:23:07 2016: Request 113591 was acted upon.
>> Transaction: Ticket created by rsk@intralogics.net
>> Queue: Time-Piece
>> Subject: strftime SEG fault in Windows 7 64-bit
>> Broken in: (no value)
>> Severity: (no value)
>> Owner: Nobody
>> Requestors: rsk@intralogics.net
>> Status: new
>> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=113591 >
>>
>>
>> Gentlemen:
>>
>> My boss called me in to investigate a problem he was having with some
>> Perl code he wrote--and which worked fine--but which suddenly was
>> failing in two 64-bit environments.
>>
>> The simple enclosed script, "date-plus-days.pl" manifests the bug when
>> run
>> under Windows 7, 64-bit, and Strawberry Perl (v 5.22.1 built for
>> MSWin32-x86-multi-thread-64int).
>>
>> The version of Time::Piece is current, 1.31 (checked with cpan).
>>
>> The segmentation fault occurs when the input line
>> 2028-05-30 4192
>> is given to the script. The correct DATE is calculated, but the
>> module
>> Piece.xs.dll fails and causes Perl to crash.
>>
>> Nota bene:
>> *** ON A 32-BIT WINDOWS XP MACHINE ALL WORKS AS EXPECTED ****
>>
>> I have a suspicion that this has to do with overrunning a
>> number-of-seconds-since-the-epoch which cannot be represented in
>> 32-bit
>> integers.
>>
>> This turned out to be a somewhat different problem in a 64-bit
>> installation on CentOS, but in that case, the failure occurred in the
>> date calculation itself, not the strftime function--and that
>> installation of Perl had an EARLIER version of the Time::Piece module
>> than the current one, so I assume THAT bug was already fixed.
>>
>> (On the CentOS system, 2028-05-30 + 4192 days ended up being
>> 1903-10-15!
>> I did verify that the strftime function THERE, although in an
>> earlier
>> version of the module, 1.15, DOES, however, format the correct date,
>> 2039-11-21, without a problem.)
>>
>> This bug showed up in a brand new installation of the latest
>> Strawberry
>> Perl, and CPAN found nothing to update in the module.
>>
>> Nor do I see an active bug at rt.cpan.org that sounds quite the
>> same--but I do see an active bug in other uses of this function, so
>> perhaps it's a good time to submit it.
>>
>> Please contact me if you need further details to reproduce the
>> problem,
>> and apologies in advance if this is a known bug.
>>
>> Thank you for your kind attention.
>>
>> Very truly yours,
>> Robert S. Kissel
>>
>
>
> Thank you and sorry for the problems.
>
> Using your example file "date-plus-days.pl", I ran it under 64 bit
> Linux
> and 64 bit Windows 7 (with 5.22 64 bit version) and they all gave the
> output "2039-11-21"
>
> 32 bit Linux with 32 bit perl gave the output "1901-12-13" (which is
> expected given the epoch overflow)
>
> On the same Windows 7 64 bit machine running the 32 bit 5.22 version I
> I
> did get a segfault. I will look more into this but I don't know if
> running a 32 bit perl on a 64 bit OS is actually a supported or
> desirable thing to do. I will have to look into that matter first.
>
> Regards,
> Samuel Smith
