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
5.18.0 RC1 test failure on MacOSX 10.8.3 #12960
Comments
From @neilbMy email from perlbug bounced, block by spamhaus. Hopefully this will get through.
|
From @jkeenanCleaning up the forwarded report and re-posting: I got a test failure on MacOSX 10.8.3: ext/GDBM_File/t/fatal ......................................... Following the directions in INSTALL I then ran: % ./perl harness ../ext/GDBM_File/t/fatal.t Test Summary Report And then I ran: % ./perl -MTestInit ext/GDBM_File/t/fatal.t Perl Info
|
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Sun, May 12, 2013 at 06:02:05AM -0700, James E Keenan via RT wrote:
I can't replicate this (on an earlier OS X, or anywhere else) It's crashing after the last OK What happens running it under valgrind? Or if valgrind is not available, $ gdb --args ./perl -MTestInit ext/GDBM_File/t/fatal.t Note, I tried it under valgrind on OS X and Linux, and ext/GDBM_File/t/gdbm.t ==36831== Syscall param msync(start) points to uninitialised byte(s) so there will be noise like that about passing uninitialised memory to Nicholas Clark |
From @neilbOn 13 May 2013, at 19:52, "Nicholas Clark via RT" <perlbug-followup@perl.org> wrote:
Here's the gdb output: Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. I'm not at all familiar with valgrind, so here's all the output I got. Let me know if you want me to run it a different way: % valgrind ./perl -MTestInit ext/GDBM_File/t/fatal.t valgrind: m_syswrap/syswrap-amd64-darwin.c:460 (wqthread_hijack): Assertion 'VG_(is_valid_tid)(tid)' failed. sched status: Thread 1: status = VgTs_WaitSys |
From @nwc10On Mon, May 13, 2013 at 08:35:34PM +0100, Neil Bowers wrote:
No, this was exactly what I'd hoped for.
This is what I'd seen on Linux too. I think that it's a "bug" in libgdbm.
This is utterly messy and seems to be in OS code called by gdbm called by us. Sadly it seems like the best thing to do is to skip the test on this Actually, which version of libgdbm? I'm not *sure* how to answer that. Nicholas Clark |
From @neilb
I think this might be what you're after: otool -L GDBM_File.bundle Neil |
From @jhiSkip ext/GDBM_File/t/fatal.t in Darwin, too flaky. http://perl5.git.perl.org/perl.git/commitdiff/cfc6b1ed |
From [Unknown Contact. See original ticket]Skip ext/GDBM_File/t/fatal.t in Darwin, too flaky. http://perl5.git.perl.org/perl.git/commitdiff/cfc6b1ed |
From @jkeenanOn Fri May 17 18:18:55 2013, neilb wrote:
Nicholas, Neil, Given that this problem appears not to be a Perl 5 problem and that we have introduced a SKIP on the fragile test, is this ticket closable? Thank you very much. -- |
From @neilb
I think the answer to your question is probably "yes". I'm mainly replying to this because that failing test has bugged me on every version of Perl since 5.18.0 RC1 :-) I can't remember the specifics of the GDBM issue now, but wonder whether GDBM_File should have a caveat for Mac users in the BUGS section? I nearly used GDBM_File last week, but remembered this failure (thinking "there's some flakiness of GDBM_File on MacOS") and went with DBM::Deep instead. Nicholas: can you remember the specifics enough to help me with wording for such an addition? Neil |
From @jkeenanOn Mon Sep 15 06:46:27 2014, neilb wrote:
Original poster is more or less satisfied with our action. So I'm marking ticket Resolved. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#117967 (status was 'resolved')
Searchable as RT117967$
The text was updated successfully, but these errors were encountered: