28 Jun
2006
28 Jun
'06
10:54 a.m.
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(a)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????