Using gdb, I am trying to trace the function calls of a web server. I set breakpoints on every function call and when I tell gdb to 'run' it breaks at all the right places while the server starts up. Then gdb says 'Program ended with code 01' and doesn't stop at breakpoints anymore (obviously). However, the web server is still running.
I want to be able to trace the function calls made on an incoming HTTP request, so just breaking during server startup is useless to me.
Is there some trick to using gdb when tracing a daemon server so that it doesn't just end like above?
You didn't say which server you are trying to trace, but likely it is Apache.
Detailed instructions are here. Note the -X command line argument, which prevents httpd from forking children.
Also note that the instructions are the first result for this search.
set follow-fork-mode child
see https://sourceware.org/gdb/onlinedocs/gdb/Forks.html for example
Related
Is there a way, in Linux, to make the electron executable copy or redirect output sent to its console to the shell console, i.e. when I run it from a terminal?
For instance, if I run, in a shell, electron foo.js, where foo.js contains simply console.log("foo"), I get the foo message echoed back to my terminal.
However, when I run a React app, the output of console.log is directed to the browser's console (as explained here).
Is there a way to copy/redirect the outputs sent to the browser Console, so that they will also be sent to the shell console? This can be very useful for some kinds of debugging (e.g. using grep and regexes).
Alternatively, if there are other methods than console.log that allow writing to the shell which created the browser process, that would also be helpful.
Edit: #0stone0 mentioned the difference between server code and client code; from the point of view of debugging, since I am running a local process, the browser could very well decide to copy its console output to stdout/stderr. I fail to see why technically Chromium could not do it; requiring an API or websockets for this use case seems excessive, but if that is indeed necessary (e.g. for security reasons), that is a valid answer for me.
I just found a way, thanks to this question:
Q: Does anyone know of a way to save the console.log output in Chrome to a file? Or how to copy the text out of the console?
A: Enable logging from the command line using the flags:
--enable-logging --v=1
I then combined it with the answer to this question to set the Chromium flag in my Electron app:
app.commandLine.appendSwitch('enable-logging');
And that is enough for me to get messages in my console, such as:
[1234:0328/3923.5981:INFO:CONSOLE(2)] "logging", source: file:///home/user/app/main.js
i am from java background and have used debugger in eclipse(java).
i have installed postgresql 9.3 as stated in this link: https://wiki.postgresql.org/wiki/Working_with_Eclipse
The debugger works fine for the server(which waits and accepts incoming client connections).
When i connect a client with: $ psql test .Does the server create a new thread for the client?
Is it possible to attach debugger and set breakpoints in parser.c or executor.c in postgresql source files so that i can analyse how postgresql queries are executed?
I have tried attaching debugger and set breakpoints in parser.c and executed some queries in the client.But it doesnt stop at the breakpoint.
Thanks in Advance
When i connect a client with: $ psql test, Does the server create a new thread for the client?
No. The server creates a new postgres (or, on Windows, postgres.exe) process that communicates with the postmaster and other processes via shared memory and signals. PostgreSQL uses a shared-nothing-by-default multiprocessing architecture rather than a shared-everything-by-default multithreading architecture.
Is it possible to attach debugger and set breakpoints in parser.c or executor.c in postgresql source files so that i can analyse how postgresql queries are executed?
Yes, if your debugger can follow backend forks from the postmaster, or if you directly attach your debugger to the backend you wish to debug. The latter is more common unless you're debugging backend startup.
A typical workflow is:
Connect with psql
SELECT pg_backend_pid()
Connect the debugger to that process ID
Set breakpoints and watches as desired and resume execution
In the same psql session, run the query you want to debug backend execution of
Switch to the debugger when it traps and start debugging
This works on Linux with gdb and Windows with Visual Studio. Presumably it works with Eclipse too.
More at the developer FAQ.
It is possible to instead debug the postmaster and use gdb's multi-process debugging features with follow-fork-mode, detach-on-fork, schedule-multiple and non-stop options, but it's complicated to get right, noisy, and will be confusing if you're used to gdb's normal break behaviour. It's also a bit awkward because PostgreSQL uses signals that gdb also uses, so some hacks are required to work around that. See a blog post I wrote on the topic earlier.
I recommend keeping it simple and attaching using pg_backend_pid.
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
I am a beginner and I want to understand some basics of Client-Server applications written in C (I understand web based server-client applications written in Java, PHP ,etc).
To be more specific, I am talking about ZABBIX which is a client-server tool (Zabbix_server is a server and zabbix_agentd is a client, both written in C).
Zabbix_server asks zabbix_agentd for data and zabbix_agents responds accordingly.
I have imported zabbix codes on Eclipse and have tried to debug to understand codes. A complete execution of zabbix_agentd on Eclipse just launched the daemon successfully and created a child process. But when I check the log, I find that different functions are being called which had not come in the way while debugging. It means, these functions are called by some process, may be inetd, etc. (correct me if i am wrong). I tried to find inetd on RHEL 6.4 OS, but it was no where found (using "service inetd status", "find").
So, how those functions are being called? Can anyone please give me ideas about that?
Please suggest me how to use those calling requests to further debug my client application.
One thing I have noticed while debugging Eclipse is that, I get below error after calling fork():
No source available for "fork() at 0x36ca0acbc0"
I couldn't understand the impact of the above error as the daemon keeps on working after this error also.
I browsed through similar error different people getting and found that their binaries were not linked to sources. However, my binaries are linked to sources also. I mean, expanding the binary of zabbix_agentd shows several *.h and *.c files.
As this error terminates the debugger immediately but the line of code at this occurrence is the last line of the source file also. So, I cannot say if I need to take care for this error.
Is this error the reason why I am not able to view other functions being called?
Please let me know if more information is required.
Thanks in advance.
Regards,
Rohit
I have my SNMP Extension Agent DLL that is called by the Windows SNMP Service (snmp.exe) everytime i do an snmpwalk (another console application) .I want to step into my DLL code that is called from the above Windows
Service. How do i go about doing that?
Thanks
Som
Normally, you'd attach your debugger to the running process that uses your DLL and then interact with the debugger as you'd normally do.
In Visual Studio 2008, you'd do that by using Debug > Attach To Process, then select the correct process. At least that's how I vaguely remember doing it before.
You can attach to running service from visual studio as Timo Geusch suggests. After that you can set a breakpoint in your code. You also can add call to DebugBreak function in the place you want to debug your library. This can help you if the code you want to debug is executed before you can attach to process (if your code executed in handler of service start event for example).
EDIT: You can attach to any service, even if you don't have debugging information for it, but in this case you wouldn't be able to see stack trace above your function call.