I have written a code to print backtrace in a linux machine using a backtrace function call specified in the "execinfo.h" header file. I need to get this code working on a freebsd machine as well. I am getting a compiler error for "execinfo.h" in Freebsd machines. I am thinking of using conditional macros to solve the problem, but I am not able to find a proper documentation for printing backtrace in Freebsd machines.
For those who come in modern times to this thread, just use -lexecinfo. See man backtrace.
Up to FreeBSD 10:
libexecinfo is available as devel/libexecinfo in FreeBSD ports. If it does not work you should report the error.
Later versions have libexecinfo in the base system.
Related
My understanding is that Wine directly executes the machine code contained in a PE executable. Assuming this is correct, what happens if the machine code contains a system call, which would obviously not be understood by Linux? Does Wine somehow intercept them? If so, how exactly does it work?
I tried to find the answer in Wine's source code, but found it daunting. I couldn't even find the place where the machine code is actually executed.
I have a process waiting on a futex:
# strace -p 5538
Process 5538 attached - interrupt to quit
futex(0x7f86c9ed6a0c, FUTEX_WAIT, 20, NULL
How can I best debug such a situation? Can I identify who holds the futex? Are there any tools similar to ipcs and ipcrm but for futexes?
Try using gdb -p *PID* and then run where or bt to see a backtrace.
It won't be spectacularly useful with binaries and libraries that have had their debugging symbols stripped, but you may be able to deduce a fair bit from the context. It might be able to indicate to you which part of a complex process is hanging, and then you could examine the right part of the sources to search for the lock.
I have the same problem with a piece of c++ code. Running ubuntu 12.10 64bit. It looks to like a similar problem in 2007, where the libc was buggy (and maybe still is?).
I start a pthread which runs a traceroute in a system call. Printf before and after the system indicate, that the operating system hangs on the system call, WITHOUT executing the traceroute.
I am not sure if my linux is broken once again because of the ubuntu update, or if it's a libc related bug. Since a lot of applications seem to have "similar" problems, I assume it's stuck somewhere in the userspace.
My c++ code runs perfectly on 32bit systems and even 64bit osx, so i assume that ubuntu 12.10 + 64bit libc combination is broken.
The question is how to execute aout-format binary (I mean old format which for example used on FreeBSD before it has migrated to ELF) on Linux system. Is there a possibility to do so without extra coding (is there some existing solution)? Probably it should be in form of kernel module or patch for the Linux kernel. Another solution could be user-space launcher (may be even run-time linker). I have searched for something similar but was unable to found something. I have not yet checked difference in system calls interfaces, if you have some comments about that, you are welcome to provide them.
P.S. I know that writing user-space launcher for aout static binary is quite trivial but the question is about some existing solution.
Check for CONFIG_BINFMT_AOUT in your kernel config.
If your kernel has /proc/config.gz:
zgrep CONFIG_BINFMT_AOUT /proc/config.gz
On Ubuntu and the like:
grep CONFIG_BINFMT_AOUT /boot/config-$(uname -r)
Kernel option was CONFIG_BINFMT_AOUT, not sure if it's still around or necessary.
Looking for a way to disassemble the running kernel. Can I do it through /dev/kmem? I am running linux 2.6.32. Or can I use a kernel module to run through the kernel. I am beginner to this. Please help.
All I want to do is check the kernel image for some malicious module, by looking at the whether some specific instruction occured or not.
Try the Linux Kernel Debugger.
Update
As I said, try the Linux Kernel Debugger. Look in the linked article, about halfway down the page, where it says:
To disassemble instructions starting
from the routine schedule. The number
of lines displayed depends on the
environment variable IDCOUNT:
[0]kdb> id schedule
I'd like to prevent would-be hackers from attaching to my binary on Linux systems. I see that ptrace DENY_ATTACH can be used on OSX. Is there such option that can be used on linux? How about on Windows?
Thanks for any info!
Such a system call requires kernel support. Even if it existed in Linux, it would be fairly easy to disable by compiling your own kernel.
In linux, ptrace returns -1 if the process is being ptraced.
So, one solution would be, inside your program, try to attach to your process, and if you get a -1, you will know that the program is being ptraced.