Tag Info

Hot answers tagged

34

I knew I was grasping at straws, but UNIX never fails! Here's how I managed it: bash$ gdb --pid 8909 ... Loaded symbols for /lib/i386-linux-gnu/i686/cmov/libnss_files.so.2 0xb76e7424 in __kernel_vsyscall () Then at the (gdb) prompt I ran the command, call write_history("/tmp/foo") which will write this history to the file /tmp/foo. (gdb) call ...


27

A segmentation fault is the result of a memory access violation. The program has referred to a memory address outside of what was allocated to it, and the OS kernel responds by killing the program with SIGSEGV. This is a mistake, since there is no point in trying to access inaccessible memory (it cannot be done). Mistakes of this sort are easy to make, ...


22

Start your bash script with bash -x ./script.sh or add in your script set -x. Additional with bash 4.1 or later: If you want to write the debug output to a separate file, add this to your script: exec 5> debug_output.txt BASH_XTRACEFD="5" See: http://stackoverflow.com/a/25593226/3776858 If you want to see line numbers add this: PS4='$LINENO: ' ...


20

You can stop both processing by sending them SIGSTOP (replace pid1 and pid2 by the actual PIDs or use killall and the application name): kill -SIGSTOP pid1 pid2 The printing on the terminal (or wherever stdout is redirected to) should stop. Then continue one of them using kill -SIGCONT pid1 If the error messages appear immediately, you know its the ...


19

There isn't a universal way, but you can make an educated guess by looking for things only done by one compiler. GCC is the easiest; it writes a .comment section that contains the GCC version string (the same string you get if you run gcc --version). I don't know if there's a way to display it with readelf, but with objdump it's: objdump -s --section ...


15

On most unix systems, you can use GDB. gdb -batch -ex bt -p 1234 There's also pstack (not a standard utility, you'll probably have to install it manually). It looks like an equivalent of AIX's procstack. But on my Debian wheezy amd64, it seems to always error out. On i386, for a program compiled without debugging symbols, it doesn't print any symbol, not ...


14

My personal flavor for Linux Kernel development is Debian. Now for your points: As you probably guessed Ubuntu doesn't bring nothing new to kernel ease kernel development afaik, apart from what's already available in Debian. For e.g. make_kpkg is a Debian feat. and not Ubuntu. Here are some links to get you started on common Linux Kernel development tasks ...


14

The standard method to debug scripts in most Bourne-based shells, like bash is to write set -x at the top of your script. This will make bash more verbose about what's being done/executed, and how arguments are evaluated. -x Print commands and their arguments as they are executed. this is useful for either, the interpreter or inside scripts. For example: ...


14

My first step would be to run strace on the process, best strace -s 99 -ffp 12345 if your process ID is 12345. This will show you all syscalls the program is doing. How to strace a process tells you more. If you insist on getting a stacktrace, google tells me the equivalent is pstack. But as I do not have it installed I use gdb: tweedleburg:~ # sleep ...


14

Two answers have been given for finding the stack trace of a program (remember to install debugging symbols first!). If you want to find out where a system call got stuck, examine /proc/PID/stack, which lists the kernel stack. Example: $ cat /proc/self/stack [<ffffffff81012b72>] save_stack_trace_tsk+0x22/0x40 [<ffffffff81213abe>] ...


13

On Linux, assuming you want to know what is writing to the same resource as your shell's stdout is connected to, you could do: strace -fe write $(lsof -t "/proc/$$/fd/1" | sed 's/^/-p/') That would report the write() system calls (on any file descriptor) of every process that have at least one file descriptor open on the same file as fd 1 of your shell.


13

Many of the flags that can be passed to bash on the command line are set flags. set is the shell built-in which can toggle these flags at runtime. For example, calling a script as bash -x foo.sh is basically the same as doing set -x at the top of the script. Knowing that set is the shell built-in responsible for this lets us know where to look. Now we can ...


13

Using set -x I always use set -x and set +x. You can wrap areas that you want to see what's happening with them to turn verbosity up/down. #!/bin/bash set -x ..code to debug... set +x log4bash Also if you've done development work and are familiar with the style of loggers that go by the names log4j, log4perl, etc., then you might want to make use of ...


12

I think, general principles of network troubleshooting are: Find out at what level of TCP/IP stack(or some other stack) occurs the problem. Understand what is the correct system behavior, and what is deviation from normal system state Try to express the problem in one sentence or in several words Using obtained information from buggy system, your own ...


12

However, are there any other clever tools/methods to see if process listening on TCP port receives a message? You can use strace with -e trace=network. This is what it prints on accepting a TCP connection, receiving an HTTP request, sending an HTTP response and closing the connection: $ strace -v -f -e trace=network -p `cat logs/my_server.pid` Process ...


11

This reference seems to have answers to your questions, titled: Linux Kernel Development Second Edition. excerpt printk() The kernel print function, printk(), behaves almost identically to the C library printf() function. Indeed, throughout this book we have not made use of any real differences. For most intentions, this is fine; printk() is simply ...


10

If you can change the source code, Dmalloc is great; it will list which pointers were unfreed and (for code built with debugging symbols) exactly which line they were allocated on. If you can't, Valgrind is pretty much the standard for that sort of thing. I generally find Valgrind somewhat harder to use, but it has way more features and doesn't involve ...


10

You can only debug a setuid or setgid program if the debugger is running as root. The kernel won't let you call ptrace on a program running with extra privileges. If it did, you would be able to make the program execute anything, which would effectively mean you could e.g. run a root shell by calling a debugger on /bin/su. If you run Gdb as root, you'll be ...


9

There is a system call named ptrace. It takes 4 parameters: the operation, the PID of the target process, an address in the target process memory, and a data pointer. The way the last 2 parameters are used is dependent on the operation. For example you can attach/detach your debugger to a process: ptrace(PTRACE_ATTACH, pid, 0, 0); ... ptrace(PTRACE_DETACH, ...


9

There are many ways to handle suspend and hibernate capabilities, many of the old methods are deprecated. This has made searching for solutions difficult, as it seems every solution is completely unrelated to the next. With that said... The method currently recommended, advocated from http://pm-utils.freedesktop.org/wiki/, should be available for most ...


9

You've asked way too much in one question—well, technically not, as I guess "is this understanding correct" can be answered quickly: no. But that's not a useful answer. First, you're right about ata_piix and sd_mod apparently being compiled-in to your kernel. That's a choice you make configuring the kernel—you can omit it, include it, or include it as a ...


9

You can do this with gdb: commands ni and si run a single instruction at time. Command n runs the next line of code, for most values of "next". For n (and the corresponding s) you have to have compiled so that debugging symbols appear in the executable. This stackoverflow answer gives a couple of methods of doing this more-or-less visually. The gdb ...


8

The methods will depend on the kind of the problem. In general "How To Ask Questions The Smart Way" by Eric S. Raymond and Rick Moen is sometimes a helpful advice to focus on the problem and to check if you have thought about important parts of the problem. Your first source of information during debugging are the logfiles your system/application writes. ...


8

ltrace -- A library call tracer. It only works on Linux and in a small subset of architectures. Calls to dlopen()ed libraries will not be traced. Further pointers from man page and /etc/ltrace.conf


8

As far as i know there is no way to directly do that as cron has a special purpose - running schedules commands at a specific time. So the best thing is to either to manually create a crontab entry or write a script which removes and resets the environment.


8

One hacky way is just to write your comments as arguments to a no-op command. Particularly useful might be the : null utility: set -x : Some interesting notes on the following are ... results in: + : Some interesting notes on the following are... The colon command does nothing, accepts whatever arguments you give it, and always succeeds. You get an ...


7

valgrind is amazingly helpful.


7

You can try using the strings command. It will create a lot of text output; by checking it you might guess the compiler. pubuntu@pubuntu:~$ strings -a a.out |grep -i gcc GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Here I know it's compiled with gcc but you can always redirect strings output to a file and examine it. There is one very good utility called peid ...


7

First things first, debug the module? Just see if you can load it up in gdb it might point you straight at a line that uses the relevant variable(or close to it). oh, and you might find this article useful


7

xtrace output goes to stderr, so you could redirect stderr to /dev/null: ikwtd() { echo do stuff } 2> /dev/null If you still want to see the errors from the commands run inside the functions, you could do ikwtd() ( set +x exec 2>&3 3>&- echo do stuff ) 3>&2 2> /dev/null See also this locvar.sh which contains a few ...



Only top voted, non community-wiki answers of a minimum length are eligible