[Serusers] still battling ser

Weiter Leiter bp4mls at googlemail.com
Wed Jun 28 11:14:41 CEST 2006


Hi,

Nearly enough. In gdb promt, after the sigsegv received, run
'backtrace'. And post the whole output. Also, attach the output of 'ser -V'.

WL.

nick wrote:
> nick wrote:
>> 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 at 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 at 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????
>>
>>
>>
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
> I ran it without forking via the command line option -D, it decided to
> listen to me finally:
>
>
> and gave me this:
>
> Starting program: /usr/local/sbin/ser -D -dddddddd
>               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
>
> WARNING: no fork mode
> acc - initializing
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000002a9578516f in insert_tmcb (cb_list=0x0, types=1,
>     f=0x2a955675c7 <acc_onreq>, param=0x0) at t_hooks.c:99
> 99              cbp->next = cb_list->first;
>
>
> Is this something that someone qualified can work with?????
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>




More information about the sr-users mailing list