Hot answers tagged debugging
15
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 ...
10
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 ...
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 ...
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
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, ...
8
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 ...
7
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 ...
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 ...
5
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
5
Arch is a DIY distro: there is no automated tool for bug reporting. There is, however, comprehensive guidance on the Arch Wiki for reporting bugs.
The philosophy of Arch, the Arch Way, stresses self-sufficiency and a willingness to contribute solutions, which means actively participating in bug reporting and squashing. This doesn't fit well with an ...
5
Sometimes ltrace works. In general, this calls for a debugger such as GDB. You can get an idea of which functions to put trace points or break points on by looking at the call structure in the disassembly (objdump -d /path/to/executable).
4
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 ...
4
I'm one of the authors of that patch, sorry it is so buggy :)
In general to find null pointers like this I just insert printks until I find the pointer that is null (=0), then I read the source code until I find out why.
However in this case I know that you have to disable framebuffer console or you'll get this nasty bug, which is only triggered when the ...
4
run ulimit -c 1073741824 prior to starting the program. Next time the program crashes, a core dump will be created in the working directory (named core.). You can then use GDB to open this core at any time you like.
ulimit -c XXXXX sets the maximum size of the core dump file created when a program seg faults. By default this is '0' which means not to dump ...
4
Somewhere in your ppp setup (probably either in /etc/ppp/options or at the command line), you have an option called connect followed by a command used to setup the modem for a connection. It's usually a chat script. You need to find out why that command is failing. If it is a chat script, you can make it verbose by changing it from chat blah blah... to chat ...
4
I had the same problem on Linux Mint 13 and the same output on xev, namely Control_l + f was mapped to Control_l.
My solution:
I remembered that I have xbindkeys running to enable some exotic buttons on my tablet pc.
By running xbindkeys-config and checking all key mappings defined for xbindkeys I found an entry that interfered with CTRL-F.
After ...
4
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 ...
3
From a debugging perspective, the kernel is a special "process", distinct from the user space processes, which communicate with the kernel via a sort of rpc mechanism (syscalls) or mapped memory..
I don't think you can see the kernel's data structure simply by inspecting some random user process.
Another problem is, that every user space process ...
3
The usual trick is to have something (possibly a signal like SIGUSR1) trigger the program to fork(), then the child calls abort() to make itself dump core.
from os import fork, abort
(...)
def onUSR1(sig, frame):
if os.fork == 0:
os.abort
and during initialization
from signal import signal, SIGUSR1
from wherever import onUSR1
(...)
...
3
Uh, how do you know about the segfault anyway?
There is a kernel log message at priority info. It shows the executable name without the directory part. On some architectures, the debug.exception-trace sysctl must be set. Some architectures require a compile-time option and kernel command line parameter (e.g. CONFIG_USER_DEBUG and user_debug on arm).
3
PM_DEBUG and PM_TRACE are apparently the deepest debugging facilities there are right now. When you're getting nothing meaningful from higher level logs, AFAIK this is the only mechanism to fall back on when encountering the dreaded "mysterious blank screen on resume" symptom. Most often we're dealing with a, quite often subtly, broken device driver. You can ...
3
If you want a single, general principle for debugging, it would be this: Understand how the system works, as much as you can. Understand each component of the system, and the failure modes of each component. Be aware of which components you have changed recently, and which components may have changed or failed on their own.
If you were looking for ...
3
atop is pretty good at monitoring and logging resource usage. It can be used interactively or as a service; the debian package sets it to log to /var/log/atop.log every ten minutes (edit /etc/init.d/atop for something more precise). You can then replay the logs with atop -r /var/log/atop.log -b hh:mm -mM; mM selects a view and a sort appropriate for memory ...
3
The file /proc/$pid/stacks shows kernel stacks. On your system, memory addresses of the form ffffffff8xxxxxxx are in the space that's reserved for the kernel. There's not much documentation, you can check the source code. In contracst, the pstack program shows user-space stacks (using its knowledge of executable formats).
3
Try this as root:
PM_DEBUG=true pm-suspend
Then check /var/log/pm-suspend.log for hints on what might go wrong.
If you can suspend, but not resume, there's a good article on the Ubuntu wiki on how to debug this problem.
3
I know it's not a perfect solution, but you can try to eliminate processes one by one to figure out which one do the mess, but first:
Create another user, and test it there to verify if it's a user-settings specific.
Change window manager to simplest possible (twm?) to see if it's a window manager specific.
Good luck.
2
Massif (from valgrind) is one of the best way to find memory leaks. Repeat your suspicious code (or run your program long enough) and dump the result with ms_print. Usually, the call stack is giving you enough information to fix it.
With GDB, you can try to attach to a running program and call functions such as malloc_stats()
If your program is written in ...
2
You could try taking a look at the ~/.xsession-errors file. If you're lucky you might find some failed assertion or error in there.
You could also install the gnome-panel-dbg package and attach gdb to the running panel to get a backtrace in case of crash (more information here).
2
You can also use this clever script that counts the numbers of various CPU instructions used by the binary. It is based on parsing objdump output. Beware that it can take quite a long time to finish if you use it on a big binary.
2
Do you have an Intel graphics chipset? I was getting what sounds like the same problem on my ThinkPad X200s running Ubuntu 10.10, and this workaround (from 2008!) fixed it for me:
http://ubuntuforums.org/showpost.php?p=6105510&postcount=12
Only top voted, non community-wiki answers of a minimum length are eligible
