On startup of my application with gdb, I am getting weird errors that look like:
unable to read unknown load command 0x22
The whole trace looks something like this:
[Session started at 2009-12-17 10:28:24 -0500.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".tty /dev/ttys003
Loading program into debugger…
sharedlibrary apply-load-rules all
warning: Unable to read symbols for "#loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle" (file not found).
warning: Unable to read symbols from "Sparkle" (not yet mapped into memory).
unable to read unknown load command 0x22
unable to read unknown load command 0x22
Program loaded.
run
[Switching to process 9051 local thread 0x2e03]
Running…
unable to read unknown load command 0x22
unable to read unknown load command 0x22
I have tried every sort of analysis tool available, haven't been able to find any memory leaks or anything that could cause these unknown errors.
Help?
This problem has a two part fix.
One make sure that you have Sparkle Copying in in the Copy Frameworks build phase.
Secondly, adding the following script as a buildphase after the Copy Frameworks helps fix the load path on some machines.
install_name_tool -change "#loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle" "#executable_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle" "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH"
Below is a screenshot of what this buildphase looks like in my project.
Build Phase Example http://grab.by/1OkU
And here is a screenshot of my target steps.
Target Steps http://grab.by/1fCu
Related
run v8's d8 command, prompt (No debugging symbols found in ./d8). after executing the command, exit the program.
here is a hint of the code.
➜ x64.debug git:(e47af00448) ✗ gdb ./d8 // this
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.6.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./d8...
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/async-hooks-wrapper.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-console.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-js.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-platforms.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-posix.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-test.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8.o': file time stamp mismatch.
(No debugging symbols found in ./d8)
expect
can be used normally.
d8 produced using the gm x64.release command
Release builds don't have debugging information. Try gm x64.debug.
That said, the error message you posted does mention .../out/x64.debug/obj/..., so it's not clear how you actually built. Are you maybe trying to force one build's debugging information into another build's GDB session? That isn't going to work.
file time stamp mismatch sounds like recompiling might fix it, have you tried that?
Also, the usual workflow is to remain in the main checkout directory, and invoke d8 as gdb -args out/x64.debug/d8 .... If that was the problem, the error would likely look different though.
Another shot in the dark: try LLDB, which may work better on MacOS.
I have a project consisting of a few libraries which is cross platform and runs and debugs just fine if all the source code is in one Visual Studio 2019 project. However, having the libraries in separate projects and I cannot debug from within the IDE at all. However, the executable will run perfectly ok from the command line in my WSL installation and on other Linux boxes. I have tried various things such as setting my LD_LIBRARY_PATH as one of the projects is a shared dynamic library, but nothing so far seems to work. Anyone have any ideas on this ? Thanks
Update: if I manually copy the dynamic library e.g.
cp libWSI.so /usr/lib/x86_64-linux-gnu/libWSI.so
debugging works. But this is not ideal.
The output I get from the Debugger is this:
=thread-group-added,id="i1"
GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Inferior 1 (process 1438) exited with code 0177]
The thread 'WSITests.out' (0x59e) has exited with code 0 (0x0).
The program '' has exited with code 177 (0xb1).
My debugger won`t start even with the libs in the same folder when using dynamic linking. I have found a workaround here: https://github.com/Microsoft/VSLinux/issues/257
You have to make a script, let`s say "debug.sh", where you add the paths to your lib folders and run the debugger with --interpreter=mi argument. I suspect this gdb argument does the magic in this case.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/c/Users/mircea.goga/source/repos/TestCoreCLRLinux/Out/
/usr/bin/gdb --interpreter=mi
In Visual Studio, set the path to this file to "Remote GDB Path" in "Debugging" section.
image
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
I’m trying to analyze a Linux kernel crash dump. The kernel was built out of 4.4.77 tree with some custom packages on top of that. The command to build the kernel was make-kpkg kernel_image debug_image, producing in 2 different debian packages. The idea is that the first package runs in production, the second package can be utilized for debugging if a problem is detected. So the “kernel_image” package was installed, configured for collecting crashes per instructions, ran, crashed and wrote a crash dump file.
I am using crash utility to analyze the dump. Running
crash vmlinux file.dump
for vmlinux file uncompressed per instructions outputs
crash: vmlinux: no .gnu_debuglink section
crash: vmlinux: no debugging data available
Installing the “debug_image” package does not change that.
I noticed that the “debug-image” package contains its own vmlinux file; it is placed in /usr/lib/debug/lib/modules/4.4.77+/ upon installation. Running
crash /usr/lib/debug/lib/modules/4.4.77+/vmlinux file.dump
Outputs
WARNING: kernels compiled by different gcc versions:
/usr/lib/debug/lib/modules/4.4.77+/vmlinux: (unknown)
dump.201802261029 kernel: 4.8.4
WARNING: kernel version inconsistency between vmlinux and dumpfile
crash: incompatible arguments:
/usr/lib/debug/lib/modules/4.4.77+/vmlinux is not SMP -- dump.201802261029 is SMP
What am I missing? Is it possible to analyze the the dump from “kernel_image” utilizing the info available in “debug_image” package?
Update: Apparently the system had a makedumpfile binary being too old for 4.4 kernels. At some point in the past the system's kernel was updated from 3.something to 4.4 but all user-mode binaries stayed as they were. That somehow caused an invalid crash dump. I could not just apt-get install newer makedumpfile (part of kdump-tools package) due to binary incompatibilities. The problem has been resolved after I re-built makedumpfile binary v 5.9 in the same dev environment as the one used to build user-mode applications for the system. Summarizing, pointing crash to vmlinux file from "debug-image" package worked for me at the end.
My kernel extension crash a several times so I want to get the correct backtrace (with function names) from the crash
Accroding to the article https://developer.apple.com/library/mac/technotes/tn2004/tn2118.html
I wanted to use gdb for this, but it seems that GDB does not understand the dump
dhcp80-241:KernelDebugKit gburanov$ sudo gdb -c /PanicDumps/core-xnu-2050.48.12-10.41.20.195-39882f44
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".
Core file contained no thread-specific data
(gdb)
I heard that it is not possible by gdb, but lldb does not work as well
dhcp80-241:KernelDebugKit gburanov$ lldb
(lldb) target create -d -c /PanicDumps/core-xnu-2050.48.12-10.41.18.191-2c2bf92f /Volumes/KernelDebugKit/mach_kernel
Loading kernel debugging from /Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/mach_kernel.py
LLDB version LLDB-179.5
settings set target.process.python-os-plugin-path "/Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
command script import "/Volumes/KernelDebugKit/mach_kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
xnu debug macros loaded successfully. Run showlldbtypesummaries to enable type summaries.
error: Unable to find process plug-in for core file '/PanicDumps/core-xnu-2050.48.12-10.41.18.191-2c2bf92f'
(lldb)
What is the correct way to work with core dumps?
That looks like an lldb from Xcode 4.6 - I can't remember the state of core file support that version had -- and the kernel debug commands provided with the kenel dSYM aren't going to work with that lldb. You'll need to install Xcode 5.1 to get this to work.
The fact that gdb said it couldn't find a register context in the core file may indicate that you have a corrupt/truncated core file. The lldb in Xcode 5.1 will be a better check on that.