From @neilb

My email from perlbug bounced, block by spamhaus. Hopefully this will get through.

From​: neil@​bowers.com
Subject​: 5.18.0 RC1 test failure on MacOSX 10.8.3
Date​: 11 May 2013 23​:30​:37 BST
To​: perlbug@​perl.org
Reply-To​: neil@​bowers.com

This is a bug report for perl from neil@​bowers.com,
generated with the help of perlbug 1.39 running under perl 5.18.0.

-----------------------------------------------------------------
[Please describe your issue here]

I got a test failure on MacOSX 10.8.3​:

ext/GDBM_File/t/fatal ......................................... FAILED--non-zero wait status​: 4

Following the directions in INSTALL I then ran​:

% ./perl harness ../ext/GDBM_File/t/fatal.t
../ext/GDBM_File/t/fatal.t .. All 8 subtests passed

Test Summary Report
-------------------
../ext/GDBM_File/t/fatal.t (Wstat​: 4 Tests​: 8 Failed​: 0)
Non-zero wait status​: 4
Files=1, Tests=8, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.02 cusr 0.00 csys = 0.04 CPU)
Result​: FAIL

And then I ran​:

% ./perl -MTestInit ext/GDBM_File/t/fatal.t
1..8
ok 1 - use GDBM_File;
ok 2 - Can find next available file descriptor
ok 3 - Check that we cannot open fileno 3. $! is Bad file descriptor
ok 4 - The object isa GDBM_File
ok 5 - dup fileno 3
ok 6 - close fileno 3, out from underneath the GDBM_File
ok 7 - Trapped error when attempting to write to knobbled GDBM_File
ok 8 - expected error message from GDBM_File
Illegal instruction

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=library
severity=medium
module=GDBM_File
---
Site configuration information for perl 5.18.0​:

Configured by neilb at Sat May 11 19​:57​:27 BST 2013.

Summary of my perl5 (revision 5 version 18 subversion 0) configuration​:

Platform​:
osname=darwin, osvers=12.3.0, archname=darwin-2level
uname='darwin tucumcari.local 12.3.0 darwin kernel version 12.3.0​: sun jan 6 22​:37​:10 pst 2013; root​:xnu-2050.22.13~1release_x86_64 x86_64 '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler​:
cc='gcc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include',
optimize='-O3',
cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'
ccversion='', gccversion='4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries​:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib -L/opt/local/lib'
libpth=/usr/local/lib /opt/local/lib /usr/lib
libs=-lgdbm -ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector'

Locally applied patches​:
RC1

---
@​INC for perl 5.18.0​:
./lib
/usr/local/lib/perl5/site_perl/5.18.0/darwin-2level
/usr/local/lib/perl5/site_perl/5.18.0
/usr/local/lib/perl5/5.18.0/darwin-2level
/usr/local/lib/perl5/5.18.0
.

---
Environment for perl 5.18.0​:
DYLD_LIBRARY_PATH (unset)
HOME=/var/root
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/local/apache/bin​:/usr/local/bin​:/Developer/usr/bin​:/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/opt/X11/bin
PERL_BADLANG (unset)
SHELL=/bin/tcsh

From @jkeenan

Cleaning up the forwarded report and re-posting​:

I got a test failure on MacOSX 10.8.3​:

ext/GDBM_File/t/fatal .........................................
FAILED--non-zero wait status​: 4

Following the directions in INSTALL I then ran​:

% ./perl harness ../ext/GDBM_File/t/fatal.t
../ext/GDBM_File/t/fatal.t .. All 8 subtests passed

Test Summary Report
-------------------
../ext/GDBM_File/t/fatal.t (Wstat​: 4 Tests​: 8 Failed​: 0)
Non-zero wait status​: 4
Files=1, Tests=8, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.02 cusr 0.00
csys = 0.04 CPU)
Result​: FAIL

And then I ran​:

% ./perl -MTestInit ext/GDBM_File/t/fatal.t
1..8
ok 1 - use GDBM_File;
ok 2 - Can find next available file descriptor
ok 3 - Check that we cannot open fileno 3. $! is Bad file descriptor
ok 4 - The object isa GDBM_File
ok 5 - dup fileno 3
ok 6 - close fileno 3, out from underneath the GDBM_File
ok 7 - Trapped error when attempting to write to knobbled GDBM_File
ok 8 - expected error message from GDBM_File
Illegal instruction

Flags:
category=library
severity=medium
module=GDBM_File

Site configuration information for perl 5.18.0:

Configured by neilb at Sat May 11 19:57:27 BST 2013.

Summary of my perl5 (revision 5 version 18 subversion 0) configuration:

Platform:
osname=darwin, osvers=12.3.0, archname=darwin-2level
uname='darwin tucumcari.local 12.3.0 darwin kernel version 12.3.0: sun
jan 6 22:37:10 pst 2013; root:xnu-2050.22.13~1release_x86_64 x86_64 '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -I/opt/local/include',
optimize='-O3',
cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -I/opt/local/include'
ccversion='', gccversion='4.2.1 (Based on Apple Inc. build 5658) (LLVM
build 2336.11.00)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector
-L/usr/local/lib -L/opt/local/lib'
libpth=/usr/local/lib /opt/local/lib /usr/lib
libs=-lgdbm -ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup
-L/usr/local/lib -L/opt/local/lib -fstack-protector'

Locally applied patches:
RC1


@INC for perl 5.18.0:
./lib
/usr/local/lib/perl5/site_perl/5.18.0/darwin-2level
/usr/local/lib/perl5/site_perl/5.18.0
/usr/local/lib/perl5/5.18.0/darwin-2level
/usr/local/lib/perl5/5.18.0
.


Environment for perl 5.18.0:
DYLD_LIBRARY_PATH (unset)
HOME=/var/root
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/local/apache/bin:/usr/local/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
PERL_BADLANG (unset)
SHELL=/bin/tcsh

The RT System itself - Status changed from 'new' to 'open'

From @nwc10

On Sun, May 12, 2013 at 06​:02​:05AM -0700, James E Keenan via RT wrote​:

Cleaning up the forwarded report and re-posting​:

I got a test failure on MacOSX 10.8.3​:

ext/GDBM_File/t/fatal .........................................
FAILED--non-zero wait status​: 4

Following the directions in INSTALL I then ran​:

% ./perl harness ../ext/GDBM_File/t/fatal.t
../ext/GDBM_File/t/fatal.t .. All 8 subtests passed

Test Summary Report
-------------------
../ext/GDBM_File/t/fatal.t (Wstat​: 4 Tests​: 8 Failed​: 0)
Non-zero wait status​: 4
Files=1, Tests=8, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.02 cusr 0.00
csys = 0.04 CPU)
Result​: FAIL

And then I ran​:

% ./perl -MTestInit ext/GDBM_File/t/fatal.t
1..8
ok 1 - use GDBM_File;
ok 2 - Can find next available file descriptor
ok 3 - Check that we cannot open fileno 3. $! is Bad file descriptor
ok 4 - The object isa GDBM_File
ok 5 - dup fileno 3
ok 6 - close fileno 3, out from underneath the GDBM_File
ok 7 - Trapped error when attempting to write to knobbled GDBM_File
ok 8 - expected error message from GDBM_File
Illegal instruction

I can't replicate this (on an earlier OS X, or anywhere else)
This is a new test (new since v5.16.0).

It's crashing after the last OK

What happens running it under valgrind? Or if valgrind is not available,
under a debugger - eg

$ gdb --args ./perl -MTestInit ext/GDBM_File/t/fatal.t
...
(gdb) run

Note, I tried it under valgrind on OS X and Linux, and ext/GDBM_File/t/gdbm.t
and the underlying gdbm library doesn't seem to be clean​:

==36831== Syscall param msync(start) points to uninitialised byte(s)
==36831== at 0x100695F22​: msync (in /usr/lib/libSystem.B.dylib)
==36831== by 0x1011A2920​: XS_GDBM_File_DESTROY(cv*) (in /Volumes/Stuff/Perl/perl4/lib/auto/GDBM_File/GDBM_File.bundle)
==36831== by 0x1001A1D36​: Perl_pp_entersub (in ./perl)
==36831== by 0x1000457AF​: Perl_call_sv (in ./perl)
==36831== by 0x1001E3E0C​: S_curse (in ./perl)
==36831== by 0x1001E0DF9​: Perl_sv_clear (in ./perl)
==36831== by 0x1001E450E​: Perl_sv_free2 (in ./perl)
==36831== by 0x1001A523A​: S_SvREFCNT_dec (in ./perl)
==36831== by 0x1001DA2E0​: S_sv_unmagicext_flags(sv*, int, mgvtbl*, unsigned int) (in ./perl)
==36831== by 0x1001DA46F​: Perl_sv_unmagic (in ./perl)
==36831== by 0x10028B257​: Perl_pp_untie (in ./perl)
==36831== by 0x100132FE2​: Perl_runops_debug (in ./perl)
==36831== Address 0x1011cb004 is not stack'd, malloc'd or (recently) free'd
==36831==

so there will be noise like that about passing uninitialised memory to
syscalls.

Nicholas Clark

From @neilb

On 13 May 2013, at 19​:52, "Nicholas Clark via RT" <perlbug-followup@​perl.org> wrote​:

I can't replicate this (on an earlier OS X, or anywhere else)
This is a new test (new since v5.16.0).

It's crashing after the last OK

What happens running it under valgrind? Or if valgrind is not available,
under a debugger - eg

$ gdb --args ./perl -MTestInit ext/GDBM_File/t/fatal.t
...
(gdb) run

Here's the gdb output​:

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
[Switching to process 16033 thread 0x1503]
0x00007fff9880fe29 in _dispatch_mgr_invoke ()
(gdb) where
#0 0x00007fff9880fe29 in _dispatch_mgr_invoke ()
#1 0x00007fff9880f9ee in _dispatch_mgr_thread ()

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
==43474== Memcheck, a memory error detector
==43474== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==43474== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==43474== Command​: ./perl -MTestInit ext/GDBM_File/t/fatal.t
==43474==
==43474== WARNING​: Support on MacOS 10.8 is experimental and mostly broken.
==43474== WARNING​: Expect incorrect results, assertions and crashes.
==43474== WARNING​: In particular, Memcheck on 32-bit programs will fail to
==43474== WARNING​: detect any errors associated with heap-allocated data.
==43474==
--43474-- ./perl​:
--43474-- dSYM directory is missing; consider using --dsymutil=yes
1..8
ok 1 - use GDBM_File;
ok 2 - Can find next available file descriptor
ok 3 - Check that we cannot open fileno 3. $! is Bad file descriptor
==43474== Syscall param write(buf) points to uninitialised byte(s)
==43474== at 0x2574AA​: write (in /usr/lib/system/libsystem_kernel.dylib)
==43474== by 0x74278F​: gdbm_open (in /opt/local/lib/libgdbm.4.dylib)
==43474== by 0x73C5E1​: XS_GDBM_File_TIEHASH (in /usr/local/src/perl-5.18.0-RC2/lib/auto/GDBM_File/GDBM_File.bundle)
==43474== by 0x10008933E​: Perl_pp_entersub (in ./perl)
==43474== by 0x10001CA95​: Perl_call_sv (in ./perl)
==43474== by 0x1000C0841​: Perl_pp_tie (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001C361​: perl_run (in ./perl)
==43474== by 0x100000FE7​: main (in ./perl)
==43474== Address 0x1007331e4 is 4 bytes inside a block of size 4,096 alloc'd
==43474== at 0xC713​: malloc (vg_replace_malloc.c​:274)
==43474== by 0x74266E​: gdbm_open (in /opt/local/lib/libgdbm.4.dylib)
==43474== by 0x73C5E1​: XS_GDBM_File_TIEHASH (in /usr/local/src/perl-5.18.0-RC2/lib/auto/GDBM_File/GDBM_File.bundle)
==43474== by 0x10008933E​: Perl_pp_entersub (in ./perl)
==43474== by 0x10001CA95​: Perl_call_sv (in ./perl)
==43474== by 0x1000C0841​: Perl_pp_tie (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001C361​: perl_run (in ./perl)
==43474== by 0x100000FE7​: main (in ./perl)
==43474==
ok 4 - The object isa GDBM_File
ok 5 - dup fileno 3
ok 6 - close fileno 3, out from underneath the GDBM_File
UNKNOWN workq_ops option 32
UNKNOWN workq_ops option 32

valgrind​: m_syswrap/syswrap-amd64-darwin.c​:460 (wqthread_hijack)​: Assertion 'VG_(is_valid_tid)(tid)' failed.
==43474== at 0x23803A7AB​: ???
==43474== by 0x23803AA7F​: ???
==43474== by 0x2380D465C​: ???

sched status​:
  running_tid=0

Thread 1​: status = VgTs_WaitSys
==43474== at 0x2546C2​: semaphore_wait_trap (in /usr/lib/system/libsystem_kernel.dylib)
==43474== by 0x2FFE1E​: xpc_connection_send_message_with_reply_sync (in /usr/lib/system/libxpc.dylib)
==43474== by 0x9D27E3​: __block_global_11 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D2726​: withDaemonConnection (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D2687​: ___CFPreferencesIsManaged_block_invoke_0 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x6E0B5​: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib)
==43474== by 0x6E040​: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==43474== by 0x8C7ACB​: _CFPreferencesIsManaged (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D7277​: -[CFPrefsManagedSource initWithDomain​:user​:byHost​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D716A​: +[CFPrefsManagedSource withSourceForIdentifier​:user​:perform​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D45FB​: -[CFPrefsSearchListSource addManagedSourceForIdentifier​:user​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D4124​: +[CFPrefsSearchListSource withSnapshotSearchList​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x8C82C8​: __CFXPreferencesCopyCurrentApplicationState (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x8C7EEF​: CFLocaleCopyCurrent (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x74EEB0​: _nl_locale_name_default (in /opt/local/lib/libintl.8.dylib)
==43474== by 0x74D073​: libintl_dcigettext (in /opt/local/lib/libintl.8.dylib)
==43474== by 0x742F3B​: gdbm_store (in /opt/local/lib/libgdbm.4.dylib)
==43474== by 0x73D15B​: XS_GDBM_File_STORE (in /usr/local/src/perl-5.18.0-RC2/lib/auto/GDBM_File/GDBM_File.bundle)
==43474== by 0x10008933E​: Perl_pp_entersub (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001CAB1​: Perl_call_sv (in ./perl)
==43474== by 0x100072097​: Perl_magic_methcall (in ./perl)
==43474== by 0x100072357​: S_magic_methcall1 (in ./perl)
==43474== by 0x100072289​: Perl_magic_setpack (in ./perl)
==43474== by 0x10006F756​: Perl_mg_set (in ./perl)
==43474== by 0x100082B2E​: Perl_pp_sassign (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001C361​: perl_run (in ./perl)
==43474== by 0x100000FE7​: main (in ./perl)

From @nwc10

On Mon, May 13, 2013 at 08​:35​:34PM +0100, Neil Bowers wrote​:

On 13 May 2013, at 19​:52, "Nicholas Clark via RT" <perlbug-followup@​perl.org> wrote​:

I can't replicate this (on an earlier OS X, or anywhere else)
This is a new test (new since v5.16.0).

It's crashing after the last OK

What happens running it under valgrind? Or if valgrind is not available,
under a debugger - eg

$ gdb --args ./perl -MTestInit ext/GDBM_File/t/fatal.t
...
(gdb) run

Here's the gdb output​:

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
[Switching to process 16033 thread 0x1503]
0x00007fff9880fe29 in _dispatch_mgr_invoke ()
(gdb) where
#0 0x00007fff9880fe29 in _dispatch_mgr_invoke ()
#1 0x00007fff9880f9ee in _dispatch_mgr_thread ()

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​:

No, this was exactly what I'd hoped for.

% valgrind ./perl -MTestInit ext/GDBM_File/t/fatal.t

ok 3 - Check that we cannot open fileno 3. $! is Bad file descriptor
==43474== Syscall param write(buf) points to uninitialised byte(s)
==43474== at 0x2574AA​: write (in /usr/lib/system/libsystem_kernel.dylib)
==43474== by 0x74278F​: gdbm_open (in /opt/local/lib/libgdbm.4.dylib)
==43474== by 0x73C5E1​: XS_GDBM_File_TIEHASH (in /usr/local/src/perl-5.18.0-RC2/lib/auto/GDBM_File/GDBM_File.bundle)
==43474== by 0x10008933E​: Perl_pp_entersub (in ./perl)
==43474== by 0x10001CA95​: Perl_call_sv (in ./perl)
==43474== by 0x1000C0841​: Perl_pp_tie (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001C361​: perl_run (in ./perl)
==43474== by 0x100000FE7​: main (in ./perl)
==43474== Address 0x1007331e4 is 4 bytes inside a block of size 4,096 alloc'd

This is what I'd seen on Linux too. I think that it's a "bug" in libgdbm.
It might not even be a bug, in as much as they are knowingly instructing
the OS to write out a large block of memory, including bits that they
are never going to read. But yes, it's a distraction.

valgrind​: m_syswrap/syswrap-amd64-darwin.c​:460 (wqthread_hijack)​: Assertion 'VG_(is_valid_tid)(tid)' failed.
==43474== at 0x23803A7AB​: ???
==43474== by 0x23803AA7F​: ???
==43474== by 0x2380D465C​: ???

sched status​:
running_tid=0

Thread 1​: status = VgTs_WaitSys
==43474== at 0x2546C2​: semaphore_wait_trap (in /usr/lib/system/libsystem_kernel.dylib)
==43474== by 0x2FFE1E​: xpc_connection_send_message_with_reply_sync (in /usr/lib/system/libxpc.dylib)
==43474== by 0x9D27E3​: __block_global_11 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D2726​: withDaemonConnection (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D2687​: ___CFPreferencesIsManaged_block_invoke_0 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x6E0B5​: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib)
==43474== by 0x6E040​: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==43474== by 0x8C7ACB​: _CFPreferencesIsManaged (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D7277​: -[CFPrefsManagedSource initWithDomain​:user​:byHost​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D716A​: +[CFPrefsManagedSource withSourceForIdentifier​:user​:perform​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D45FB​: -[CFPrefsSearchListSource addManagedSourceForIdentifier​:user​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x9D4124​: +[CFPrefsSearchListSource withSnapshotSearchList​:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x8C82C8​: __CFXPreferencesCopyCurrentApplicationState (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x8C7EEF​: CFLocaleCopyCurrent (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==43474== by 0x74EEB0​: _nl_locale_name_default (in /opt/local/lib/libintl.8.dylib)
==43474== by 0x74D073​: libintl_dcigettext (in /opt/local/lib/libintl.8.dylib)
==43474== by 0x742F3B​: gdbm_store (in /opt/local/lib/libgdbm.4.dylib)
==43474== by 0x73D15B​: XS_GDBM_File_STORE (in /usr/local/src/perl-5.18.0-RC2/lib/auto/GDBM_File/GDBM_File.bundle)
==43474== by 0x10008933E​: Perl_pp_entersub (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001CAB1​: Perl_call_sv (in ./perl)
==43474== by 0x100072097​: Perl_magic_methcall (in ./perl)
==43474== by 0x100072357​: S_magic_methcall1 (in ./perl)
==43474== by 0x100072289​: Perl_magic_setpack (in ./perl)
==43474== by 0x10006F756​: Perl_mg_set (in ./perl)
==43474== by 0x100082B2E​: Perl_pp_sassign (in ./perl)
==43474== by 0x100082462​: Perl_runops_standard (in ./perl)
==43474== by 0x10001C361​: perl_run (in ./perl)
==43474== by 0x100000FE7​: main (in ./perl)

This is utterly messy and seems to be in OS code called by gdbm called by us.
Frustratingly, it looks like "their" bug. But I don't see how to fix it.

Sadly it seems like the best thing to do is to skip the test on this
platform/compiler combination.

Actually, which version of libgdbm? I'm not *sure* how to answer that.
On an ELF system I'd "just" use ldd to find out what the .so was linking to.
But darwin isn't ELF enough, and I don't know what the analogous tool is, if
any.

Nicholas Clark

From @neilb

This is utterly messy and seems to be in OS code called by gdbm called by us.
Frustratingly, it looks like "their" bug. But I don't see how to fix it.

Sadly it seems like the best thing to do is to skip the test on this
platform/compiler combination.

Actually, which version of libgdbm? I'm not *sure* how to answer that.
On an ELF system I'd "just" use ldd to find out what the .so was linking to.
But darwin isn't ELF enough, and I don't know what the analogous tool is, if
any.

I think this might be what you're after​:

otool -L GDBM_File.bundle

Neil

From @jhi

Skip 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 @jkeenan

On Fri May 17 18​:18​:55 2013, neilb wrote​:

This is utterly messy and seems to be in OS code called by gdbm
called by us.
Frustratingly, it looks like "their" bug. But I don't see how to fix
it.

Sadly it seems like the best thing to do is to skip the test on this
platform/compiler combination.

Actually, which version of libgdbm? I'm not *sure* how to answer
that.
On an ELF system I'd "just" use ldd to find out what the .so was
linking to.
But darwin isn't ELF enough, and I don't know what the analogous tool
is, if
any.

I think this might be what you're after​:

otool -L GDBM_File.bundle

Neil

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.

--
James E Keenan (jkeenan@​cpan.org)

From @neilb

This is utterly messy and seems to be in OS code called by gdbm
called by us.
Frustratingly, it looks like "their" bug. But I don't see how to fix
it.

[...]

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?

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 @jkeenan

On Mon Sep 15 06​:46​:27 2014, neilb wrote​:

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?

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 :-)

Original poster is more or less satisfied with our action. So I'm marking ticket Resolved.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@jkeenan - Status changed from 'open' to 'resolved'