Debug Dovecot Plugin (shared library)
Hey!
I was just wondering what would be the best way to debug a plugin I am currently writing for dovecot. The plugin basically registers a new IMAP capability and I want to set a breakpoint to the "cmd_handle_new_capability" function (thats just a function name for better explaining purposes).
Right now I have opened a connection via openssl ('openssl s_client -connect example:143 -starttls imap') to be able to mess around with the my server. Then I am able to login into the server via 'a login "username" "password"' and feed the server with my self created IMAP capability command.
I know that I can start gdb and attach to an already running process via its PID. But how do I know which process I have to attach to? Looking at the output of 'top' it seems to be an instance of the 'imap' command
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13413 vmail 20 0 21004 1844 1524 S 0.0 0.0 0:00.00 Iman
But its only started the exact moment I issue my IMAP command towards the server, so of course I am not fast enough to track down the PID before the function has returned, so the process handling the command seems to be up only for the short period of time to handle the command, there is no process before which I can attach to.
My current workaround is that I put a tail onto /var/log/mail.log and from within my shared library function (cmd_handle_new_capability) I log the PID of the current process, then sleep(10) for 10 seconds, which gives me enough time to have a look at mail.log to get to know the PID which I then can attach to. But isn't there a better way to do this? Maybe attach to the process which originally creates the new process handling the IMAP command and then stepping into it?
I hope someone can help me out :)
All the best, David
On 24 Dec 2015, at 14:26, David Becher <becher.david@googlemail.com> wrote:
Hey!
I was just wondering what would be the best way to debug a plugin I am currently writing for dovecot. The plugin basically registers a new IMAP capability and I want to set a breakpoint to the "cmd_handle_new_capability" function (thats just a function name for better explaining purposes).
Right now I have opened a connection via openssl ('openssl s_client -connect example:143 -starttls imap') to be able to mess around with the my server. Then I am able to login into the server via 'a login "username" "password"' and feed the server with my self created IMAP capability command.
I know that I can start gdb and attach to an already running process via its PID. But how do I know which process I have to attach to? Looking at the output of 'top' it seems to be an instance of the 'imap' command
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13413 vmail 20 0 21004 1844 1524 S 0.0 0.0 0:00.00 Iman
But its only started the exact moment I issue my IMAP command towards the server, so of course I am not fast enough to track down the PID before the function has returned, so the process handling the command seems to be up only for the short period of time to handle the command, there is no process before which I can attach to.
My current workaround is that I put a tail onto /var/log/mail.log and from within my shared library function (cmd_handle_new_capability) I log the PID of the current process, then sleep(10) for 10 seconds, which gives me enough time to have a look at mail.log to get to know the PID which I then can attach to. But isn't there a better way to do this? Maybe attach to the process which originally creates the new process handling the IMAP command and then stepping into it?
If you need to actually login the normal way, that's pretty much the only way. Otherwise you could just run:
gdb --args /usr/libexec/dovecot/imap -u user@domain
participants (2)
-
David Becher
-
Timo Sirainen