I have an assembler program with a simple structure, a text segment and a bss segment. Similar programs have been compiled by me over a decade. It is a Forth compiler and I play tricks with the elf header.
I'm used to it that if I mess up the elf header, I can't start the program and the loader says "killed" before it even segfaults.
But now I've a user of a Fedora version 6 linux, who does the following:
as -32 lina.s
ld a.out -N -melf_i386 -o lina
./lina
and get a message "killed" and 137 as result of 'echo $?'
Clearly this procedure uses only official tools, such that the elf header should at least be valid.
The exact same procedure on other systems like my ubuntu or Debian systems lead to programs that work normally. The objdumps of the resulting programs are the same at least what the mapping of segments is concerned.
Please give me some indication of what is going on here, I have no clue of how to tackle this problem.
I'd like to stress that probably no instruction is executed, i.e. gdb refuses to run it. Like so
(gdb) run
Starting program: /home/gerard/Desktop/lina-5.1/glina32
Warning:
Cannot insert breakpoint -2.
Error accessing memory address 0x8048054: Input/output error.
(gdb)
In rare cases if an error occurs while when a process tries to execute a new program the Linux kernel will send a SIGKILL signal to that process instead of returning an error. That signal will result in the shell printing "Killed", rather than a more useful error message like "out of memory". Something about the executable you've created triggers an error that the kernel can only recover from by killing the process that tried to execute it.
Normally shells execute a program by making two system calls: fork and execve. The first system call creates a new process, but doesn't load a new executable. Instead the fork system call duplicates the process that invoked it. The second system call loads a new executable but doesn't create a new process. Instead the program running in the process is replaced by a new program from the executable.
In the process of performing the execve system call the kernel needs to discard the previous contents of the process's address space so it can completely replace it with an entirely new one. After this point the execve system call can no longer return an error code to the program that invoked it as that program no longer exists. If error occurs after this point which prevents the executable from loading then the kernel has no other option but to kill the process.
This behaviour is documented in the Linux execve(2) man page:
In most cases where execve() fails, control returns to the original
executable image, and the caller of execve() can then handle the
error. However, in (rare) cases (typically caused by resource
exhaustion), failure may occur past the point of no return: the
original executable image has been torn down, but the new image could
not be completely built. In such cases, the kernel kills the process
with a SIGKILL signal.
The message is printed by bash, according to what signal number terminated the process. "Killed" means the process received SIGKILL:
$ pgrep cat # check that there aren't other cat processes running that you might not want to kill while doing this
$ cat # in another terminal, pkill cat
Terminated
$ cat # in another terminal, pkill -9 cat (or pkill -KILL cat)
Killed
$ cat # pkill -QUIT cat or hit control-\
Quit (core dumped)
$ cat # pkill -STOP cat or hit control-z
[1]+ Stopped cat
$ fg
cat # pkill -BUS cat
Bus error (core dumped)
$ cat # pkill -PWR cat
Power failure
Bash doesn't print anything for SIGINT, because that's what control-C sends.
Run kill -l to list signal abbreviations.
$ strace cat # then pkill -KILL cat
... dynamic library opening and mapping, etc. etc.
read(0, <unfinished ...>) = ?
+++ killed by SIGKILL +++
Killed
I can't reproduce your problem with as -32 hello.s / ld -N -melf_i386 to make an executable that my kernel won't run, or that receives SIGKILL right away.
With gcc -m32 -c / ld -N, or with gcc -m32 -E hello.S > hello.s && as -32, I get a binary that prints Hello World (using sys_write and sys_exit).
// hello.S a simple example I had lying around
// Use gcc -m32 -E hello.S > hello.s to create input for as -32
#include <asm/unistd.h>
#include <syscall.h>
#define STDOUT 1
.data # should really be .rodata
hellostr:
.ascii "hello wolrd\n";
helloend:
.text
.globl _start
_start:
movl $(SYS_write) , %eax //ssize_t write(int fd, const void *buf, size_t count);
movl $(STDOUT) , %ebx
movl $hellostr , %ecx
movl $(helloend-hellostr) , %edx
int $0x80
movl $(SYS_exit), %eax //void _exit(int status);
xorl %ebx, %ebx
int $0x80
ret
You can start by using strace, to see which syscalls, if any, are issued by the executable, prior to it killing itself.
Looking at the syscalls will often point towards a clue, as to where the problem lies.
The same ininformative message "killed" appears if you're trying to run a 64 bit program on a 32 bit Linux. So my interpretation is that it is a message from the shell if it tried to load a program, and somehow didn't manage to run it.
Related
When running GNU time (/usr/bin/time) and checking for memory consumption, does its output account for the memory usage of the child processes of my target program?
Could not find anything in GNU's time manpage.
Yes.
You can easily check with:
$ /usr/bin/time -f '%M' sh -c 'perl -e "\$y=q{x}x(2*1024*1024)" & wait'
8132
$ /usr/bin/time -f '%M' sh -c 'perl -e "\$y=q{x}x(8*1024*1024)" & wait'
20648
GNU time is using the wait4 system call on Linux (via the wait3 glibc wrapper), and while undocumented, the resource usage it returns in the struct rusage also includes the descendands of the process waited for. You can look at the kernel implementation of wait4 in kernel/exit.c for all the details:
$ grep -C2 RUSAGE_BOTH include/uapi/linux/resource.h
#define RUSAGE_SELF 0
#define RUSAGE_CHILDREN (-1)
#define RUSAGE_BOTH (-2) /* sys_wait4() uses this */
#define RUSAGE_THREAD 1 /* only the calling thread */
FreeBSD and NetBSD also have a wait6 system call which returns separate info for the process waited for and for its descendants. They also clearly document that the rusage returned by wait3 and wait4 also includes grandchildren.
Envirment is:
target:x86_64 client,runs the program which is striped
Host:x86_64 server ,has code,toolchain,striped program,symbles file for debug
run gdbserver on target:
%gdbserver --multi :1234 /pathtolog/gdb.log
run program on target:
./someprogram &
[1] PID
run gdb on host:
%gdb
(gdb)target extended-remote TARGETIP:1234
(gdb)file someprogram
(gdb)setrootfs pathtorootfs
(gdb)...//set lib path etc.
(gdb)attach PID
...//load everything as normal
...//stop somewhere
(gdb)c
^C^CThe target is not responding to interrupt requests.
Stop debugging it? (y or n)
tried to find the root cause:
on the target:
gdb attach to gdbserver(yes I can use gdb on the target right now,but the target machine shall be released without gdb,symbles,etc. for size).
(gdb) b kill
Breakpoint 1 at 0xf760afb0
(gdb) c
Continuing.
when press ctrl+c from host gdb ,gdbserver will break into the breakpoint
Breakpoint 1, 0xf760afb0 in kill () from /lib/libc.so.6
(gdb)
I'v checked register,the %esp register shows like this:
(gdb) x /32wx 0xffee8070
0xffee8070: 0xfffffe0c 0x00000002 0x00000001 0x00000000
0xfffffe0c = -PID
0x00000002 = SIGINT
some program will get the signalwhen gdbserver continue .
so，kill() is good for "SOME PROGRAM",not all.
And I'v use tcpdump monitored data between gdb/gdbserver.
If kill() worked （for "GOOD" program),gdbserver will send a packet to gdb.
I'v tried sigmonitor,found out gdbserver didn't send any sigal to "BAD program" in this case.but I can call kill(pid,2) int gdbserver debuging gdb process
(gdb) call kill(PID,2)
then dmesg shows like this
[11902.060722] ==========send_signal===========
SIG 2 to 6141[a.out], tgid=6141
...
SIG 19 to 6142[a.out], tgid=6141
[11902.111135] Task Tree of 6142 = {
...
Any ideas?
Found out a possible match bug of gdbserver.
parameter of kill() called by gdbserver is -PID,not PID.
gdbserver sends SIGINT not to the process, but to the process group (-signal_pid).
But the attached process is not always a process group leader.
If not, "kill (-signal_pid, SIGINT)" returns error and fails to interrupt the attached process.
static void linux_request_interrupt (void)
{
/* Send a SIGINT to the process group. This acts just like the user
typed a ^C on the controlling terminal. */
- kill (-signal_pid, SIGINT);
+ kill (signal_pid, SIGINT);
}
This problem remained in gdb-8.1,don't know why they don't think it's a problem.
I know that we can get the value at a memory address through a C program or gdb.
Is there any way to get it by bash shell or something like "one-line" perl instruction?
Short answer... No
If you were very careful it MIGHT be possible to pass instructions into GDB and interpret the output. Look at rocky's answer if you want to try.
Its part of the unix process model that one process cannot see inside another and cannot read each other's memory. This is for security. There is a special kernal API which can be used to see into programs. But there are very few clients for this API. Off the top of my head GDB is the only one I know.
I suspect that what you're trying to achieve is either a really bad idea or can be done without reading a program's memory.
The following possibly gets close to what you may want. And if not, hopefully you'll be able to adapt.
I'll say at the outset though that you are extremely vague at what you mean by "memory address". Below I am going to take that to mean the address of the current instruction executed which I will use the gdb command "backtrace" to get. Adapt the gdb command from "bt" to whatever it is you were thinking of to get the "memory address".
Let's say your program is sleeper-for-pid with process id 3963
sudo gdb --ex 'bt 1' --batch -nx -p 3963
will run gdb attached to the process and give a backtrace of the most recent entry. Here is an example:
sudo gdb --ex 'bt 1' --batch -nx -p 3963
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) #0 0x00007f5dee71f2f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
If you really just want the line with the address, you'd grep for #0, e.g.
sudo gdb --ex 'bt 1' --batch -nx -p 3963 | grep '#0'
(gdb) #0 0x00007f5dee71f2f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
And if you just want the address you might have to do a further cut, e.g.
$ sudo gdb --ex 'bt 1' -nx -p 3963| grep '#0' | cut -d' ' -f 4
0x00007f5dee71f2f0
If you don't know the process id, you might be able to use pidof. For example if the command name is sleeper-for-pid:
$ sudo gdb --ex 'bt 1' --batch -nx -p $(pidof sleeper-for-pid)
And "sudo" may or may not work for you or be needed.
Personally, instead of just the most recent backtrace entry I prefer more than that. So bt 1 might get adjusted to bt 3 or bt for a more full back trace.
Hopefully this is enough to get you started .
I know that we can get the value at a memory address through a C program or gdb Are there any way to get it by bash shell or something like "one-line" perl instruction??
A shell is just a program. What you asking to do is rather meaningless. Assuming a shell did allow you to inspect a memory address (and you could easily modify a shell or write your own to do so), The value of a memory address is for the shell's process. Any other process is going to have a different memory value at the same address.
I have a process running on an embedded system (linux).
its STDOUT/STDERR is the console which is on a serial port.
I would like to redirect its ouputs (standard and error) to that of an SSH session.
I have read you can do similar operations with GDB, but I don't know how you would redirect to the SSH session's STDOUT/STDERR instead of to a file.
I can't do it to a file because of low disk resources. Also I have seen some examples using a named pipe, but I don't have mkfifo command available. I do have GDB.
Also, assuming this is possible, would the process terminate when I close the SSH session? If so, could I redirect back before I do?
Thanks.
You can do it as long as you can call libc functions from gdb.
#ssh root#embedded
Query daemon output location:
# ls -l /proc/`pidof daemon`/fd/1
/proc/13202/fd/1 -> /dev/null
It can be not null, it can point to some other console or even some pipe or file, store this location somewhere. Query your ssh session output location:
# ls /proc/self/fd/1 -l
lrwx------ 1 root root 64 дек. 15 16:51 /proc/self/fd/1 -> /dev/pts/9
or simply call tty if you have it.
Now goes the work:
# gdb -p `pidof daemon`
..
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) call open("/dev/pts/9",2,0)
$1 = 0x3
(gdb) call dup2(3,2)
$2 = 0x2
(gdb) call dup2(3,1)
$3 = 0x1
(gdb) quit
Detaching from program: /root/daemon, process 13202
daemon output/errorput
Repeat the same steps before exit from ssh session, just replace /dev/pts/9 with initial output location in the open syscall.
On my machine I have an aarch64 binary, that is statically compiled. I run it using qemu-aarch64-static with the -g 6566 flag. In another terminal I start up gdb-multiarch and connect as target remote localhost:6566.
I expect the binary to raise a signal for which I have a handler defined in the binary. I set a breakpoint at the handler from inside gdb-multiarch after connecting to remote. However, when the signal arises, the breakpoint is not hit on gdb-multiarch. Instead, on the terminal that runs the binary, I get a message along the lines of :-
[1] + 8388 suspended (signal) qemu-aarch64-static -g 6566 ./testbinary
Why does this happen? How can I set a breakpoint on the handler and debug it? I've tried SIGCHLD and SIGFPE.
This works for me with a recent QEMU:
$ cat sig.c
#include <stdlib.h>
#include <signal.h>
#include <stdio.h>
void handler(int sig) {
printf("In signal handler, signal %d\n", sig);
return;
}
int main(void) {
printf("hello world\n");
signal(SIGUSR1, handler);
raise(SIGUSR1);
printf("done\n");
return 0;
}
$ aarch64-linux-gnu-gcc -g -Wall -o sig sig.c -static
$ qemu-aarch64 -g 6566 ./sig
and then in another window:
$ gdb-multiarch
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
[etc]
(gdb) set arch aarch64
The target architecture is assumed to be aarch64
(gdb) file /tmp/sigs/sig
Reading symbols from /tmp/sigs/sig...done.
(gdb) target remote :6566
Remote debugging using :6566
0x0000000000400c98 in _start ()
(gdb) break handler
Breakpoint 1 at 0x400e44: file sig.c, line 6.
(gdb) c
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x0000000000405c68 in raise ()
(gdb) c
Continuing.
Breakpoint 1, handler (sig=10) at sig.c:6
6 printf("In signal handler, signal %d\n", sig);
(gdb)
As you can see, gdb gets control both immediately the process receives the signal and then again when we hit the breakpoint for the handler function.
Incidentally, (integer) dividing by zero is not a reliable way to provoke a signal. This is undefined behaviour in C, and the implementation is free to do the most convenient thing. On x86 this typically results in a SIGFPE. On ARM you will typically find that the result is zero and execution will continue without a signal. (This is a manifestation of the different behaviour of the underlying hardware instructions for division between the two architectures.)
i was doing some R&D for your answer and find following answer
"Internally, bad memory accesses result in the Mach exception EXC_BAD_ACCESS being sent to the program. Normally, this is translated into a SIGBUS UNIX signal. However, gdb intercepts Mach exceptions directly, before the signal translation. The solution is to give gdb the command set dont-handle-bad-access 1 before running your program. Then the normal mechanism is used, and breakpoints inside your signal handler are honored."
The link is gdb: set a breakpoint for a SIGBUS handler
It perhaps help you by considering that qemu does not change the functionality of base operations