New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storable seg faults under perl 5.8.0 solaris, maximal 64bit #6028
Comments
From schatt@schatt.comCreated by schatt@schatt.comThis is a bug report for perl from schatt@schatt.com, To: perlbug@perl.org This is a bug report for perl from schatt@schatt.com, ----------------------------------------------------------------- Here is what appears to be the relevant portion of a truss of the above: From adb, the following from the core file might be off assistance: %ccr = 0x44 xcc=nZvc icc=nZvc %asi = 0x82 ::stack ::vars Perl Info
|
From @pjfG'day Drew, It's been a few years, but I'm helping clean out Perl 5 bug reports. ;) On Tue Oct 22 00:23:17 2002, schatt@schatt.com wrote:
Perl 5.8.0 was known to have quite a few issues, and there's a good Cheerio, Paul -- |
The RT System itself - Status changed from 'new' to 'open' |
@pjf - Status changed from 'open' to 'resolved' |
From schatt@schatt.comUnder 5.10.0, Solaris, with 64 bit integers, ext Storable still fails ext/Storable/t/attach_errors..................................FAILED-- On Jul 2, 2008, at 12:39 AM, Paul Fenwick via RT wrote:
|
From p5p@perl.wizbit.beCiteren Drew Schatt <schatt@schatt.com>:
Can you send the output of perl -V? On cpanteters I see the following reports of Solaris for Storable http://www.nntp.perl.org/group/perl.cpan.testers/2008/06/msg1668441.html : http://www.nntp.perl.org/group/perl.cpan.testers/2008/04/msg1296110.html : http://www.nntp.perl.org/group/perl.cpan.testers/2007/11/msg811340.html And/or is it possible that you build perl-current (blead) to see if Kind regards, Bram |
p5p@spam.wizbit.be - Status changed from 'resolved' to 'open' |
From @HugmeirOn Sat Jul 05 12:20:00 2008, p5p@perl.wizbit.be wrote:
Turns out that under sparc, use64bitint and use64bitall are implicitly But in any case, these failures appear to be gone in newer versions of |
@cpansprout - Status changed from 'open' to 'resolved' |
From @nwc10On Fri, Apr 27, 2012 at 08:45:41AM -0700, Brian Fraser via RT wrote:
Brian has now also built 5.10.0 on his Sparc Solaris machine, 64 bit, and Looking at the original bug report: Received signal #11, SIGSEGV [default] and ::stack I think that it's attempting to read the SvFLAGS() on a NULL SV pointer: void which will be at offset 0xC on a machine with 64 bit addresses (and a 32 bit Which "can't happen", as the calling code should have allocated a new SV Given that the build is optimised: optimize='-O', it's reminding me of problems we've had with another routine in sv.c which So I'm not sure whether it's a subtle bug in the compiler's optimiser, or But I think we have to close the bug as we know that current Sparc compilers Nicholas Clark |
Migrated from rt.perl.org#18049 (status was 'resolved')
Searchable as RT18049$
The text was updated successfully, but these errors were encountered: