Tag Info

Hot answers tagged

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 ...


8

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 ...


5

The octal representation eases the interpretation of the exit code for small values, which are the most commonly used. Should this number, which is a byte, been printed in decimal, finding which signal interrupted a process would require a little bit of calculation while in octal, they can be read as they are: a process exits with status 5, gdb displays 05 ...


4

eval does a printf of its arguments and then runs it as a command. So you can take your printf argument list, insert set $MyVar = at the beginning, and eval it. (gdb) eval "set $MyVar = \"Hello %d\"", 7 (gdb) print $MyVar $2 = "Hello 7"


4

Run ps -l on the process ID and check the S (“state”) column. If the state is R, then your process is executing code. If the process remains in state R and strace doesn't show it executing any system call, then the process is trapped in a very long, possibly infinite computation. If the process is and remains in state D, then it is blocked in a system call. ...


4

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 (...) ...


2

You could try using gcore. Is that an option for you?


2

On Linux, you could enable mtrace in your program, but it is a code change. On OpenBSD, you could try the malloc stats. Google's leak checker might also be worth a look, and unlike mtrace you may be able to use LD_PRELOAD to avoid recompilation.


2

%:8 is a valid filename-modifier, so it is being interpreted by Vim as a part of the :! command. You can use expand('%') to manually expand %, and then properly quote it with shellescape(…,1): :map <F9> :exe '!gdbset bp' shellescape(expand('%').':'.line('.'),1)<CR><CR> :map <F8> :exe '!gdbset clear bp' ...


2

You can debug a program even if not all the libraries have debuginfo, you just won't be able to follow into the library in terms of source code. Most of the time the problems aren't in the library anyway.


2

Gdb doesn't automatically run the executable for you, it just loads it. This way you can set things up (e.g. breakpoints) as you wish first. The "run" command at the (gdb) prompt will start execution. This also allows you to specify command-line arguments to tshark, eg: (gdb) run -i lo Will run tshark the same way tshark -i lo would.


2

Of course it won't stop, you didn't even set a break point. i.e b __libc_start_main Look at this message: Program exited normally. means gdb started it, and completed execution normally.


2

Compilers can be configured to generate extra information with the executable and/or libraries that aid debugging. With this extra information, your debugger can show the original source code and variable names amongst other things. Unfortunately, this debugging information take up a lot of space on the system. Considering that they are hardly ever used ...


2

Norman Matloff's book on debugging: The Art of Debugging is quite good, though I don't know if you would consider it advanced. There is also his online tutorial, Guide to Faster, Less Frustrating Debugging, which might be an earlier version of the book. There is also a tutorial My debugging tutorial, linked from the page Norm Matloff's DDD Tutorial. ...


2

A quick solution would be to simply remove whole /usr/local in case you haven't installed anything else there (according to out little detour in comments, I think that is the case). So sudo mv /usr/local /usr/_local will get rid of whatever gunk is there (you can delete the directory later, when you're sure it contains nothing important). Then instead of ...


2

I don't think the permission denied is necessarily talking about the traditional permissions bits (rwx..), rather I'd be suspicious of something like SELinux or AppArmor which might be denying your process access. I do not have access to a ArchLinux system but there is something similar under Fedora that is discussed here in this Fedora Wiki topic: ...


2

I think the application you're looking for is called cpulimit. This isn't a command that's normally included with a system so you'll have to install it either via your distros package manager (Ubuntu/Debian) or from source. Ubuntu/Debian $ apt-cache search cpulimit cpulimit - tool for limiting the CPU usage of a process So installation would go like ...


2

gdb will ask you to confirm certain commands, if the value of the confirm setting is on. From Optional Warnings and Messages: set confirm off Disables confirmation requests. Note that running GDB with the --batch option (see -batch) also automatically disables confirmation requests. set confirm on Enables confirmation requests (the default). ...


1

This blurb on the Sun Studio 12 website would seem to imply that they're basically useless. excerpt - http://docs.oracle.com/cd/E19205-01/819-5257/blabs/index.html If Your Core File Is Truncated If you have problems loading a core file, check whether you have a truncated core file. If you have the maximum allowable size of core files set too ...


1

No. gdb is packaged by a maintainer, glibc is packaged by another maintainer, gcc, libstdc and so on all all packaged by different maintainers. To package the debuginfo for these along with gdb would take considerable coordination. Each time one of the packages changed, the gdb maintainer would have to repackage and release. It would become quite ...


1

Keep in mind that Wireshark and its suite of related tools (mergecap, TShark, etc.) are all open-source. Perhaps you'll find it easier to read the source, as opposed to stepping through disassembly? The TShark application in particular is a single C source file (tshark.c) in the Wireshark source code distribution, which can be downloaded here: ...


1

gdbserver Sounds like you're looking for gdbserver. gdbserver is a control program for Unix-like systems, which allows you to connect your program with a remote GDB via target remote---but without linking in the usual debugging stub. Example On the target machine You need to have a copy of the program you want to debug. gdbserver does not need ...


1

Another option is to use a slow hardware - some kind of inexpensive ARM-based board like Raspbery Pi or (slightly more powerful) Compulab Trimslice should do. They've got a limited amount of memory, slow CPU yet can run a full Linux system - Fedora, Debian, and a few other distros have an ARM version.


1

What the user can do using gdb they can also do directly, so if they want to hide some nefarious activity, it is quite easy to do so (and probably simpler directly than by screwing around with gdb). What exactly do you want to gain by doing this? Maybe we can suggest a solution to your real problem.


1

There's no read-only mode for gdb, and gdb isn't the only way to debug a program anyway (it has no special permissions). Gdb uses ptrace underneath, and the ptrace permissions are all-or-nothing. There are security frameworks that restrict the use of ptrace. For example, Recent Ubuntu versions restrict ptrace to the parent process by default. But these ...


1

If you don't want to allow devs to change things, why don't you give them a coredump ? A coredump is a dump of the memory map of the process. With this and the binary who generate the coredump, you can debug your application without running it (just need debug information). To generate a coredump, use gcore command.


1

Better configure for User Mode (Linux running as a normal user process). BOCHS is painfully slow, and you still have a kernel in charge that you can't look into easily. BTW, kernels like 1.0 won't manage UM Linux (that came much later), and I don't know if 2.0 handled it either. If you want simple, you should perhaps look at Xv6, a V6 Unix (as in Lyon's ...


1

Enable and refresh the debug repos. http://download.opensuse.org/debug/distribution/11.4/repo/oss/ http://download.opensuse.org/debug/update/11.4/ zypper ar -f -n "openSUSE-11.4-Debug" http://download.opensuse.org/debug/distribution/11.4/repo/oss/ repo-debug zypper ar -f -n "openSUSE-11.4-Update-Debug" http://download.opensuse.org/debug/update/11.4/ ...


1

Here's a way to start the process in a stopped state if you will. Use a bash script doing: echo $BASHPID; kill -STOP $BASHPID; exec sudo -u unpriviledged_user -g the_group_if_not_primary command Make that run in the background. Then start gdb, and attach to the pid that was printed. You'll have to step through the exec command with gdb, but you'll be ...



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