nick wrote:
A followup to my problem, I rebuilt the entire system, and have compiled 0.9.6 from scratch. The system works just fine, with a whole bunch of modules, but as soon as I add in the acc.so module *boom*
I remember reading that the acc module has now been divided into different parts, do I need to compile the acc module seperately (I plan on using acc_db) ???
thanks for any ideas you can point me towards..
BTW, I may rebuild the binaries again, to see if I can get debugging to work, but I haven't been able to extract anything useful from gdb as of yet... _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Can anyone tell me how to get ser to stop forking???????
I have fork=no in my ser.cfg but when I load /usr/local/sbin/ser into gdb, then use the command run:
[root@sipserver ~]# gdb /usr/local/sbin/ser GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run Starting program: /usr/local/sbin/ser 192.168.1.93 [192.168.1.93]:5060 192.168.1.93 [192.168.1.93]:5060 Listening on udp: 192.168.1.93 [192.168.1.93]:5060 tcp: 192.168.1.93 [192.168.1.93]:5060 Aliases: tcp: pc-00093:5060 udp: pc-00093:5060
Detaching after fork from child process 3304.
Program exited normally.
----------------------------
of course, the core dump is called core.3305 3305 being the PID of the process forked, even though I don't want it to fork.
How can I run a stack trace on something that won't even obey it's own config file????