|
I
hope that you have passed it very well in your vacations that would be great to be able to take vacations now me but here the summer is in January and February. I try to follow your steps exactly, to debug openser in kedevelop, I run the openser in a konsole with: openser -E -ddddddd -f openser.cfg but if fork=no the openser stop working. and I don't begin debug. ----- Original Message ----- From: Ron Winacott To: Javier Ramirez Cc: devel@openser.org Sent: Monday, July 24, 2006 10:17 AM Subject: Re: [Devel] kdevelop ? Javier, Sorry, I started a two week vacation just after sending the first reply. I am back now. (and still getting through the thousands of waiting email :-)) From within kdeveloper (it uses gdb under the covers) you need to setup the debugger to start the openser process with the correct command line options. Then after openser starts, (with fork=no in the openser.cfg) you can interrupt the openser process to set a break point in your modules code. Now continue (resume) the running process and send a message to openser. Now that said, it may not work because the debugger is looking at the wrong process. The way I run a debugger (gdb) against OpenSER is to start the process normally (with fork=no, log_stderror=yes, children=1 in the openser.cfg) then run the "openserctl ps" command to get the list of processes. The one named "n pid receiver child=0 ....." remember the "pid" number (second number in the list) and then attach the debugger (gdb) to that process. When the debugger attaches it will stop the process, so you can set a break point in your module code then continue the process running. Now when the receiver process receives a SIP message and calls into your module code it will stop (at the break point) to allow you to debug it. Note that some timing issues may come up if you stop the process to long, the SUA will most likely retransmit the message and could time out. But you can step through the processing of the message until openser is done with it. To attach to a running process with gdb use the command "gdb pid" You will need to (or should) build openser and your module with -g for the debug information. You can also set the source code directory via the command line option -d dir to gdb so the debugger can locate the source code. Because openser uses multi-process module and shared memory, it makes it one of the hardest processes to debug with a debugger. You must make sure you are debugging the correct process that is running your code. Also because openser uses dynamic loaded libraries as the modules, the name space (symbols) of your modules are late binding and not seen in the global namespace (symbol table) of the debugger. This is why only the hardest problems doe I try to debug this way. I most cases a well places LOG() call with the correct data will show me the problem. hope this helps, and sorry for the delay, ronw On Sunday 16 July 2006 12:05, Javier Ramirez wrote: > hello ? > ----- Original Message ----- > From: Javier Ramirez > To: Ron Winacott ; devel@openser.org > Sent: Friday, July 14, 2006 11:11 AM > Subject: Re: [Devel] kdevelop ? > > > I don't undestand. > How attach/debug openser ? > > best regards > > > > > Javier, > The problem is kdevelop must debug (attach its self to) a main process > and the modules in OpenSER/SER ae dynamically loaded libraries (*.so = > shared object) To debug the module code, you must attach/debug openser then > set a break point in your module code so when the openser.cfg > line "loadmodule /usr/local/openser/modules/YourMod.so" is run openser > will call dl_open() and locate the module expore structure. Then it will > call the modules exported initialization function. (mod_init() or something > along those lines, depending on what you called it., look at the source in > the struct module_exports exports { structure) > > Once you have stopped the debugger in your module you should be able to > see the source, symbols, etc of your module and set break points. > > The other issues (bigger one in my mind) is you must start openser > in "non-forking" mode to stop it from creating a bunch of listener > processes where in each one you are running a copy of your module. In the > openser.cfg set "fork=no" to stop it from forking. Also you waht to make > sure you debug the correct process. If you start openser, then run > "openserctl ps" you will see a list of processes. You what to debug the > "receiver" process. It is the one that will call into your module. > > Hope this helps, > ronw > > -- > Ron Winacott - SOMA Networks, Inc. > --- > The scientists of today think deeply instead of clearly. One must be sane > to think clearly, but one can think deeply and be quite insane. > - Nikola Tesla > > > > ----- Original Message ----- > From: Ron Winacott > To: devel@openser.org > Cc: Javier Ramirez > Sent: Thursday, July 06, 2006 3:15 PM > Subject: Re: [Devel] kdevelop ? > > On Thursday 06 July 2006 11:15, Javier Ramirez wrote: > > Hi, I have a problem with my module, > > when I try debug using kdevelop, rhis don't show me a debug of my > > module, only show the debug of openser. > > > > How I configure kdevelop to see the debug of any module? > > or, can you recomend any program to use for this ? > > best regards > > Javier Ramirez > > --------------------------------------------------------------------------- >--- > > > _______________________________________________ > Devel mailing list > Devel@openser.org > http://openser.org/cgi-bin/mailman/listinfo/devel -- Ron Winacott - SOMA Networks, Inc. Work: 1-416-348-1580 - [EMAIL PROTECTED] Home: 1-905-433-8913 - [EMAIL PROTECTED] __________ NOD32 1.1672 (20060721) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com |
_______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
