Bug 288363 - valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
Summary: valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_...
Status: RESOLVED WORKSFORME
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.7.0
Platform: macOS (DMG) macOS
: NOR major
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-06 22:44 UTC by Brian Budge
Modified: 2015-07-10 09:45 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Budge 2011-12-06 22:44:39 UTC
+++ This bug was initially created as a clone of Bug #196335 +++

I built valgrind 3.7.0 on my mac osx version 10.6.8 laptop.  I ran configure without arguments, and allowed it to install in the default locations (/usr/local...).  I run valgrind on this very simple program:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **args) {
  int *foo = (int*)malloc(24);
  
  for(int i = 0; i < 7; ++i)
    foo[i] = i;
  for(int i = 7; i--; ) 
    printf("%d\n", foo[i]);

  return 0;
}

compiled with g++ -g.  My gcc version is 4.2.1.

The output from running valgrind -v -d is as follows:

> valgrind -v -d ./a.out
--37259:1:debuglog DebugLog system started by Stage 1, level 1 logging requested
--37259:1:launcher no tool requested, defaulting to 'memcheck'
--37259:1:launcher valgrind_lib = /usr/local/lib/valgrind
--37259:1:launcher arch 'x86' IS installed
--37259:1:launcher arch 'amd64' IS installed
--37259:1:launcher arch 'arm' IS NOT installed
--37259:1:launcher arch 'ppc32' IS NOT installed
--37259:1:launcher arch 'ppc64' IS NOT installed
--37259:1:launcher selected arch 'amd64'
--37259:1:launcher launcher_name = /usr/local/bin/valgrind
--37259:1:launcher launching /usr/local/lib/valgrind/memcheck-amd64-darwin
--37259:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
--37259:1:main     Welcome to Valgrind version 3.7.0 debug logging
--37259:1:main     Checking current stack is plausible
--37259:1:main     Checking initial stack was noted
--37259:1:main     Starting the address space manager
--37259:1:main     Address space manager is running
--37259:1:main     Starting the dynamic memory manager
--37259:1:mallocfr newSuperblock at 0x700000001000 (pszB 4194272)  owner VALGRIND/tool
--37259:1:mallocfr deferred_reclaimSuperblock at 0x700000001000 (pszB 4194272)  (prev 0x0) owner VALGRIND/tool
--37259:1:main     Dynamic memory manager is running
--37259:1:main     Initialise m_debuginfo
--37259:1:main     VG_(libdir) = /usr/local/lib/valgrind
--37259:1:main     Getting launcher's name ...
--37259:1:main     ... /usr/local/bin/valgrind
--37259:1:main     Get hardware capabilities ...
--37259:1:main     ... arch = AMD64, hwcaps = amd64-sse3-cx16
--37259:1:main     Getting the working directory at startup
--37259:1:main     ... /Users/budgeb/Downloads/valgrind-3.7.0
--37259:1:main     Split up command line
--37259:1:main     (early_) Process Valgrind's command line options
--37259:1:main     Create initial image
--37259:1:initimg  Loading client
--37259:1:initimg  Setup client env
--37259:1:main     Setup file descriptors

valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
==37259==    at 0x1380340C7: ???
==37259==    by 0x138034304: ???
==37259==    by 0x138034CA0: ???
==37259==    by 0x13803A55D: ???
==37259==    by 0x13803E4ED: ???
==37259==    by 0x1380395A3: ???

sched status:
  running_tid=0


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
Comment 1 Laurent Bonnaud 2012-04-04 08:29:43 UTC
I had the same assertion failure in valgrind with Ubuntu 12.04 and this package version:

Package: valgrind
Version: 1:3.7.0-0ubuntu3

This happens while valgrinding amule that crashes on my system.
Comment 2 Laurent Bonnaud 2012-04-04 08:49:51 UTC
This bug is a duplicate of bug #275673, but I cannot mark it as such.
Comment 3 Tom Hughes 2012-04-04 09:05:37 UTC
I think it's very hard to say conclusively that it is a duplicate without further investigation of both bugs.

In particular given that this one involves a very simple program, there is likely some MacOS specific issue going on here.
Comment 4 Garrett Johnson 2012-05-19 23:12:09 UTC
I am currently having this same issue on OSX 10.7 and thought perhaps I could resurrect this thread. I had the issue on 3.7 and thought I would give the trunk a try too, but the same issue occurs.

Program:
#include <stdio.h>

int main() {
    printf("Hello World");
    return 0;
}

Output:
~/Projects/learning/lcthw/week1 $ valgrind -v -d ./ex2
--19105:1:debuglog DebugLog system started by Stage 1, level 1 logging requested
--19105:1:launcher no tool requested, defaulting to 'memcheck'
--19105:1:launcher valgrind_lib = /usr/local/lib/valgrind
--19105:1:launcher arch 'x86' IS installed
--19105:1:launcher arch 'amd64' IS installed
--19105:1:launcher arch 'arm' IS NOT installed
--19105:1:launcher arch 'ppc32' IS NOT installed
--19105:1:launcher arch 'ppc64' IS NOT installed
--19105:1:launcher selected arch 'amd64'
--19105:1:launcher launcher_name = /usr/local/bin/valgrind
--19105:1:launcher launching /usr/local/lib/valgrind/memcheck-amd64-darwin
--19105:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
--19105:1:main     Welcome to Valgrind version 3.8.0.SVN debug logging
--19105:1:main     Checking current stack is plausible
--19105:1:main     Checking initial stack was noted
--19105:1:main     Starting the address space manager
--19105:1:main     Address space manager is running
--19105:1:main     Starting the dynamic memory manager
--19105:1:mallocfr newSuperblock at 0x700000001000 (pszB 4194272)  owner VALGRIND/tool
--19105:1:mallocfr deferred_reclaimSuperblock at 0x700000001000 (pszB 4194272)  (prev 0x0) owner VALGRIND/tool
--19105:1:main     Dynamic memory manager is running
--19105:1:main     Initialise m_debuginfo
--19105:1:main     VG_(libdir) = /usr/local/lib/valgrind
--19105:1:main     Getting launcher's name ...
--19105:1:main     ... /usr/local/bin/valgrind
--19105:1:main     Get hardware capabilities ...
--19105:1:main     ... arch = AMD64, hwcaps = amd64-sse3-cx16-avx
--19105:1:main     Getting the working directory at startup
--19105:1:main     ... /Users/gjohnson/Projects/learning/lcthw/week1
--19105:1:main     Split up command line
--19105:1:main     (early_) Process Valgrind's command line options
--19105:1:main     Create initial image
--19105:1:initimg  Loading client
--19105:1:initimg  Setup client env
--19105:1:main     Setup file descriptors

valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
==19105==    at 0x238038C5B: ???
==19105==    by 0x238038F2F: ???
==19105==    by 0x238038F87: ???
==19105==    by 0x23804184D: ???
==19105==    by 0x238043463: ???
==19105==    by 0x23803E523: ???

sched status:
  running_tid=0

GCC:
sing built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
Comment 5 Garrett Johnson 2012-05-20 20:28:01 UTC
Never mind, this was the result of a configuration mistake on my part. It appears in OSX 10.6 you could up your FD limit using /etc/launchd.conf. However, in 10.7 this will actually lower the limit for non-demonized processes. After fixing that mistake everything worked just fine.
Comment 6 Julian Seward 2012-08-02 10:48:55 UTC
(In reply to comment #5)
> Never mind, this was the result of a configuration mistake on my part. It

Brian, does the same fix work for you?
Comment 7 Brian Budge 2012-08-02 17:14:50 UTC
I will try to test this soon.
Comment 8 Brian Budge 2012-08-03 03:16:27 UTC
No, I still get

 valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
==47066==    at 0x138036BB7: ???
==47066==    by 0x138036DF4: ???
==47066==    by 0x138037790: ???
==47066==    by 0x13803D330: ???
==47066==    by 0x1380415BD: ???
==47066==    by 0x13803C213: ???

sched status:
  running_tid=0

The only way I could get valgrind to run before was to increase the fd limit in my shell to one larger than 8192 (I think twice that worked)
Comment 9 Rhys Kidd 2015-03-07 09:04:54 UTC
Is this still present on current Valgrind, particularly SVN? 
There have been extensive improvements to OS X support in the interim.
Comment 10 Rhys Kidd 2015-07-10 09:45:22 UTC
Unable to reproduce with current Valgrind, and no response from original bug reporter.