I'm trying to write CMake tests to detect leaks using the leaks command line tool that comes with XCode on macOS. I've been using LSAN with the Homebrew install of LLVM, but the run times on my M1 are 100x more than what they are on an amd64 machine.
Here's an example C source file with a memory leak:
// memory-leak.c
#include <stdlib.h>
void *p;
int main()
{
p = malloc(7);
p = 0; // The memory is leaked here.
return 0;
}
After compiling with clang memory-leak.c -o memleak and running the leaks command leaks -quiet -atExit -- ./memleak, the output is
% leaks -quiet -atExit -- ./memleak
Process 22773 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
leaks Report Version: 4.0
Process 22773: 214 nodes malloced for 12 KB
Process 22773: 1 leak for 16 total leaked bytes.
1 (16 bytes) ROOT LEAK: 0x600002970050 [16]
I want to include this process as CMake test targets. The CMakeLists.txt file is:
#CMakeLists.txt
cmake_minimum_required(VERSION 3.18)
project(memleak)
find_program(LEAKS_PATH NAMES leaks REQUIRED True)
enable_testing()
add_executable(memleak memory-leak.c)
add_test(NAME memleak COMMAND leaks -quiet -atExit -- $<TARGET_FILE:memleak>)
set_tests_properties(memleak PROPERTIES WILL_FAIL True)
The resulting test hangs indefinitely. Here's the terminal command and output.
% mkdir build && cd build && cmake .. && cmake --build . && ctest --verbose
-- The C compiler identification is AppleClang 13.1.6.13160021
-- The CXX compiler identification is AppleClang 13.1.6.13160021
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/user/leakstest/build
[ 50%] Building C object CMakeFiles/memleak.dir/memory-leak.c.o
[100%] Linking C executable memleak
[100%] Built target memleak
UpdateCTestConfiguration from :/Users/user/leakstest/build/DartConfiguration.tcl
UpdateCTestConfiguration from :/Users/user/leakstest/build/DartConfiguration.tcl
Test project /Users/user/leakstest/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: memleak
1: Test command: /usr/bin/leaks "-atExit" "--" "/Users/user/leakstest/build/memleak"
1: Test timeout computed to be: 10000000
1: Process 24942 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
1:
1: Process: memleak [24942]
1: Path: /Users/USER/*/memleak
1: Load Address: 0x100208000
1: Identifier: memleak
1: Version: ???
1: Code Type: ARM64
1: Platform: macOS
1: Parent Process: leaks [24941]
1:
1: Date/Time: 2022-05-17 18:38:15.553 -0500
1: Launch Time: 2022-05-17 18:38:15.282 -0500
1: OS Version: macOS 12.3.1 (21E258)
1: Report Version: 7
1: Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
1: Analysis Tool Version: Xcode 13.3 (13E113)
1:
1: Physical footprint: 7233K
1: Physical footprint (peak): 7233K
1: ----
1:
1: leaks Report Version: 4.0
1: Process 24942: 214 nodes malloced for 12 KB
1: Process 24942: 1 leak for 16 total leaked bytes.
1:
1: 1 (16 bytes) ROOT LEAK: 0x600002840050 [16]
1:
The test never exits. I expect the test to pass since there's a memory leak and the CMake file specifies that the test will fail.
The output of build/ctest --verbose shows that leaks is picking up on the memory leak, but it seems that CTest isn't responding to leaks returning.
I've tried using a shell script that contains exec leaks -quiet -atExit -- "$#" in place of the command, but I get the same results.
I've also tried doing the same thing with a Meson build file and got the same result.
Is there something I'm missing?
Related
I'm trying to compile the same lib on two x86 separate machines.
Both use the same toolchain (exactly same set of files) but have different Glibc versions.
When I run command LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --list ./libl2ps.so I notice the following discrepancy between the 2 Linux loaders:
Machine 1 (with Glibc 2.12):
19943: find library=libm.so.6 [0]; searching
19943: search path=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:...:/ebs/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
19943: trying file=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
19943:
19943: find library=libgcc_s.so.1 [0]; searching
...
In this case the Linux loader selects lib libm.so.6 from the toolchain path based on RPATH of lib libl2ps.so.
Machine 2 (with Glibc 2.17):
10699: find library=libm.so.6 [0]; searching
10699: search path=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib:/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/./libm.so.6
10699: search cache=/etc/ld.so.cache
10699: trying file=/lib64/libm.so.6
As for Machine 1, the loader attempts from RPATH of libl2ps.so to select lib libm.so.6 from toolchain path but skip it for some reason and try further other paths. Finally it selects libm.so.6from the system path /lib64/.
The RPATH of the 2 libs lib2ps.so are exactly the same. The two files libm.so.6 are also exactly the same on both machines (checked with md5sum).
I don't understand this differences of behavior between the 2 Linux loaders.
Do you see any reason what would explain this discrepancy ?
Thank you very much for your answers.
Update:
Thank you yugr for your answer.
Output of readelf -h gives only differences on fields "Entry point address" and "Start of section headers" and there is no other differences so I think it will not help.
Regarding using dlopen()/dlerror(), I've done a little executable with the following statement:
dlopen("/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so", RTLD_LAZY);
On machine 1 it works as expected:
C++ dlopen demo
Opening libm-2.28.so...
Closing library...
On machine 2 it fails and dlerror() gives the following output:
Cannot open library: /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so: cannot open shared object file: No such file or directory
but the file libm-2-28.so really exists on my file system:
$ ls -l /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
-rwxr-xr-x 1 frperies linseeusers_lte_espoo 1682944 Oct 5 13:50 /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic- linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
This is very weird, what could lead to this situation ???
Thanks
Update 2:
That is true that I haven't pointed out that machine 1 is a RHEL6.8 distro while machine 2 is RHEL7.4 distro. I (naively?) didn't think this really matters...
On machine 1:
$ cat /proc/sys/kernel/osrelease
4.4.115-1.NSN.el6.x86_64
$ uname -a
Linux sq24-3 4.4.115-1.NSN.el6.x86_64 #1 SMP Mon Feb 12 12:35:46 CET 2018 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Notes at offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: b598468830fdf2f61eda25553b9a367c4d28cdc9
On machine 2:
$ cat /proc/sys/kernel/osrelease
3.10.0-693.el7.x86_64
$ uname -a
Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Displaying notes found at file offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 5829181bc0502233748149369108915ea7b10e8f
Does it help ?
Thanks
Update 3:
$ readelf -n libm.so.6
Notes at offset 0x00000238 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 0d84c7247dd76008c096719043e5592735a1c4bd
Notes at offset 0x0000025c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.4.0
So, how to interpret this ABI version number set to 4.4.0 ??
Thanks
Thank you yugr and Employed Russian for your answers!!
I will give it a try by upgrading my Kernel version on Machine 2.
Thanks
Regards
The error message that you see is the infamously confusing ENOENT errno. I see two instances of it in dl-load.c:
checking OS compatibility
loading non-setuid to setuid process
I suspect the first one fails in your case which would mean that OS kernel is incompatible between two machines. ld.so manpage indeed says that
Each shared object can inform the dynamic linker of the
minimum kernel ABI version that it requires. (This
requirement is encoded in an ELF note section that is viewable
via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run
time, the dynamic linker determines the ABI version of the
running kernel and will reject loading shared objects that
specify minimum ABI versions that exceed that ABI version.
NT_GNU_ABI_TAG is 4.4.0 which means that you run a program expecting a minimum 4.4 kernel on a 3.10 kernel. Theoretically newer Glibc should run on older kernels as well but in your case Glibc was probly built with explicit --enable-kernel flag which prevents it's usage on kernels before 4.4 (see e.g. this explanation of --enable-kernel).
As a workaround, you may try to fool Glibc by overriding kernel version on machine 2 via
export LD_ASSUME_KERNEL=4.4.0
but it may not work if libm makes 4.4-specific syscalls that are not really present on 3.10.
I have been running my application successfully in CentOs6.6. Recently, the hardware(motherboard and RAM) was updated and my application is getting killed now without any reason at all.
[root#localhost PktBlaster]# ./PktBlaster
Killed
File and ldd output
[root#localhost PktBlaster]# file PktBlaster
PktBlaster: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[root#localhost PktBlaster]# ldd PktBlaster
not a dynamic executable
Output of strace
[root#localhost PktBlaster]# strace ./PktBlaster
execve("./PktBlaster", ["./PktBlaster"], [/* 30 vars */] <unfinished ...>
+++ killed by SIGKILL +++
Killed
GDB
[root#localhost PktBlaster]# gdb PktBlaster
(gdb) break main
Breakpoint 1 at 0x43d664: file VTP.c, line 544.
(gdb) run
Starting program: /root/Veryx/PktBlaster/PktBlaster
During startup program terminated with signal SIGKILL, Killed.
While debugging, observed that the bss memory is huge(~6GB). The system has 4GB RAM and I think this could be the reason for the issue.
[root#localhost PktBlaster_1Gig]# size build/unix/bin/PktBlaster
text data bss dec hex filename
375551 55936 6747541120 6747972607 19235e3ff build/unix/bin/PktBlaster
The application contains many .h files and many datastructures and so it is difficult for me to identify why BSS is been raised to 6GB.
Could anyone please suggest how to identify which file is causing this? or any other easier way to debug this?
It seems that problem really is huge BSS size.
I have asked you to show output of LD_DEBUG=all /lib64/ld-linux-x86-64.so.2 /path/to/exe in comments.
/lib64/ld-linux-x86-64.so.2 is runtime linker which is used by OS to load your binary in process memory during execve system call. Runtime linker is responsible for parsing executable format, loading all sections and dependencies in memory, performing all required relocations and so on.
Setting environment variable LD_DEBUG to all we instruct runtime linker to generate debug output.
[root#localhost PktBlaster]# LD_DEBUG=all /lib64/ld-linux-x86-64.so.2
/root/Veryx/PktBlaster/PktBlaster
851: file=/root/Veryx/PktBlaster/PktBlaster [0]; generating link map
/root/Veryx/PktBlaster/PktBlaster: error while loading shared
libraries: /root/Veryx/PktBlaster/PktBlaster: cannot map zero-fill
pages: Cannot allocate memory
Searching for this error message in source code of runtime linker(glibc-2.17 elf/dl-load.c, lines ~1400) we see:
1393 if (zeroend > zeropage)
1394 {
1395 /* Map the remaining zero pages in from the zero fill FD. */
1396 caddr_t mapat;
1397 mapat = __mmap ((caddr_t) zeropage, zeroend - zeropage,
1398 c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED,
1399 -1, 0);
1400 if (__builtin_expect (mapat == MAP_FAILED, 0))
1401 {
1402 errstring = N_("cannot map zero-fill pages");
1403 goto call_lose_errno;
1404 }
dl-loader is in process of loading BSS segment, which by optimizations is stored in binary format as just number of bytes, that must be initialized to zero. Loader tries to allocate through mmap zero initialized memory block(MAP_ANONYMOUS) and get error from the OS:
15 #define ENOMEM 12 /* Out of memory */
From man 2 mmap:
ENOMEM No memory is available, or the process's maximum number of
mappings would have been exceeded.
So it seems that for whatever reason OS cannot fulfill loader request for memory. Either some limits are used(systemd, process limit, some security LKM, whatever) or simply there are not enough free memory in kernel.
To determine what object file generates most part of the BSS - use
objdump -j '.bss' -t *.o
i'm trying to build RabbitMQ-C (https://github.com/alanxz/rabbitmq-c) with SSL support. I have downloaded & built last openSSL version (https://github.com/openssl/openssl) , and added it. (the openssl libraries are in openssl root folder).
My terminal log :
Macbook:rabbitmq-c user$ mkdir build && cd build
Macbook:build user$ cmake .. -DOPENSSL_ROOT_DIR=~/openssl/openssl -DOPENSSL_LIBRARIES=~/openssl/openssl
Macbook:build user$ cmake --build . --target install
cmake .. :
-- The C compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_BUILD_TYPE not specified. Creating Release build
-- Found C inline keyword: inline
-- Looking for getaddrinfo
-- Looking for getaddrinfo - found
-- Looking for socket
-- Looking for socket - found
-- Looking for htonll
-- Looking for htonll - found
-- Looking for poll
-- Looking for poll - found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - not found
-- Looking for posix_spawnp in rt
-- Looking for posix_spawnp in rt - not found
-- Performing Test HAVE_GNU90
-- Performing Test HAVE_GNU90 - Success
-- Could NOT find POPT (missing: POPT_INCLUDE_DIR POPT_LIBRARY)
-- Could NOT find XMLTO (missing: XMLTO_EXECUTABLE)
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Found OpenSSL: /Users/user/openssl/openssl/libssl.a;/Users/user/openssl/openssl/libcrypto.a (found suitable version "1.1.0", minimum required is "0.9.8")
-- Building rabbitmq as a shared library - yes
-- Building rabbitmq as a static library - yes
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/user/desktop/rabbitMQ/rabbitmq-c/build
cmake --build:
Scanning dependencies of target rabbitmq
[ 1%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_framing.c.o
[ 2%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_api.c.o
[ 3%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_connection.c.o
[ 4%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_mem.c.o
[ 5%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_socket.c.o
[ 6%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_table.c.o
[ 6%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_url.c.o
[ 7%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_tcp_socket.c.o
[ 8%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_time.c.o
[ 9%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_consumer.c.o
[ 10%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_openssl.c.o
[ 11%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_openssl_hostname_validation.c.o
[ 12%] Building C object librabbitmq/CMakeFiles/rabbitmq.dir/amqp_hostcheck.c.o
[ 12%] Linking C shared library librabbitmq.dylib
Undefined symbols for architecture x86_64:
"_SSL_CTX_clear_options", referenced from:
_amqp_ssl_socket_set_ssl_versions in amqp_openssl.c.o
"_SSL_CTX_set_options", referenced from:
_amqp_ssl_socket_new in amqp_openssl.c.o
_amqp_ssl_socket_set_ssl_versions in amqp_openssl.c.o
"_TLS_client_method", referenced from:
_amqp_ssl_socket_new in amqp_openssl.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [librabbitmq/librabbitmq.4.1.4.dylib] Error 1
make[1]: *** [librabbitmq/CMakeFiles/rabbitmq.dir/all] Error 2
make: *** [all] Error 2
Now i can't understand what's wrong.
p.s. OSX 10.11,
Solved. problem was in "Cmake"(used for rabbitmq wrapper build) - he does not work correct on OS X.
I'm working on a patch for FFmpeg and need to debug my code. I'm loading an external library, and in order to test different library versions, I have them in different folders. To select which one I want to use, I've been using DYLD_LIBRARY_PATH=/path/to/lib/dir ./ffmpeg and that works okay. But when I try it within lldb, it crashes saying dyld: Library not loaded and Reason: image not found. This used to work pre-Xcode 7.1, but I just recently upgraded and it stopped working.
Here's my MVCE:
#include <stdio.h>
#include <stdlib.h>
int main() {
char* str = getenv("DYLD_LIBRARY_PATH");
if (str) puts(str);
else puts("(null)");
return 0;
}
Running this program as follows produces the output:
$ ./a.out
(null)
$ DYLD_LIBRARY_PATH=/tmp ./a.out
/tmp
That looks okay. But when I try to use lldb it fails:
$ DYLD_LIBRARY_PATH=/tmp lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) run
Process 54255 launched: './a.out' (x86_64)
(null)
Process 54255 exited with status = 0 (0x00000000)
Trying to set the environment variable inside lldb works:
lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) env DYLD_LIBRARY_PATH=/tmp
(lldb) run
Process 54331 launched: './a.out' (x86_64)
/tmp
Process 54331 exited with status = 0 (0x00000000)
lldb version (it's from Xcode 7.1):
$ lldb --version
lldb-340.4.110
Question: Is this an intended new "feature," or is this a new bug in lldb (or am I totally crazy and this never used to work)? I'm quite positive lldb used to forward the DYLD_LIBRARY_PATH environment variable, so how come it isn't anymore?
Edit: This is on OS X 10.11.1.
If this is on El Capitan (OS X 10.11), then it's almost certainly a side effect of System Integrity Protection. From the System Integrity Protection Guide: Runtime Protections article:
When a process is started, the kernel checks to see whether the main
executable is protected on disk or is signed with an special system
entitlement. If either is true, then a flag is set to denote that it
is protected against modification. …
… Any dynamic linker (dyld)
environment variables, such as DYLD_LIBRARY_PATH, are purged when
launching protected processes.
Everything in /usr/bin is protected in this fashion. Therefore, when you invoke /usr/bin/lldb, all DYLD_* environment variables are purged.
It should work to run lldb from within Xcode.app or the Command Line Tools, like so:
DYLD_LIBRARY_PATH=whatever /Applications/Xcode.app/Contents/Developer/usr/bin/lldb <whatever else>
I don't believe that copy of lldb is protected. /usr/bin/lldb is actually just a trampoline that executes the version in Xcode or the Command Line Tools, so you're ultimately running the same thing. But /usr/bin/lldb is protected so the DYLD_* environment variables are purged when running that.
Otherwise, you will have to set the environment variable inside lldb as shown in this thread:
(lldb) process launch --environment DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
or using the short -v option:
(lldb) process launch -v DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
Or, you can disable System Integrity Protection, although it serves a good purpose.
You can set an environment variable inside lldb once it is started.
$ lldb
(lldb) help env
Shorthand for viewing and setting environment variables. Expects 'raw' input (see 'help raw-input'.)
Syntax:
_regexp-env // Show environment
_regexp-env <name>=<value> // Set an environment variable
'env' is an abbreviation for '_regexp-env'
(lldb)
So that
lldb ./a.out
(lldb) env DYLD_LIBRARY_PATH=/path/to/lib/dir
(lldb) r
should work.
Tested with
$ lldb --version
lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
Can Instruments be used as a replacement for
valgrind
If one wants to check for memory leaks using instruments can it be used from the terminal?
Instruments has a command line interface:
$ instruments -h
Example usage:
$ instruments -t mytemplate -a myapp.app
For leaks, try the Leaks.tracetemplate. To see all available templates, use -s.
There is another executable, just called leaks. You can inspect any running application by giving leaks its PID:
$ echo $$
620
$ leaks 620
leaks Report Version: 2.0
Process: bash [620]
Path: /bin/bash
Load Address: 0x100000000
...
Process 620: 37983 nodes malloced for 1123 KB
Process 620: 0 leaks for 0 total leaked bytes.
Read more about leaks in the Apple developer reference library.
For Xcode 9, if you want to profile a iOS app, an example command like this:
instruments -t Zombies -w 'iPhone SE (11.0.1) [XXX] (Simulator)' MyApp.app
instruments command ref:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Recording,Pausing,andStoppingTraces.html#//apple_ref/doc/uid/TP40004652-CH12-SW3