For some reason SER won't load on my 64 bit Fedora Core 2 machines but it will work fine on all of my other 32bit Fedora Core 2 machines. Anyone know if this a known problem with SER? I haven't been able to find any info on it so I'm guessing I'm just doing something wrong. Any help would be appreciated.
WARNING: no fork mode 0(9861) DEBUG: init_mod: sl_module stateless - initializing 0(9861) DEBUG: register_fifo_cmd: new command (sl_stats) registered 0(9861) DEBUG: MD5 calculated: 88ea29e41d7a330a3a8d2ddf294ed2ce 0(9861) DEBUG: init_mod: tm 0(9861) TM - initializing... 0(9861) Call-ID initialization: '060d4f9b1d214389' 0(9861) DEBUG: register_fifo_cmd: new command (t_uac_dlg) registered 0(9861) DEBUG: register_fifo_cmd: new command (t_uac_cancel) registered 0(9861) DEBUG: register_fifo_cmd: new command (t_hash) registered 0(9861) DEBUG: lock_initialize: lock initialization started 0(9861) Segmentation fault
Thanks, Mike
On Sep 21, 2004 at 14:27, Michael Shuler mike@bwsys.net wrote:
For some reason SER won't load on my 64 bit Fedora Core 2 machines but it will work fine on all of my other 32bit Fedora Core 2 machines. Anyone know if this a known problem with SER? I haven't been able to find any info on it so I'm guessing I'm just doing something wrong. Any help would be appreciated.
What kind of 64 bit machine are you using and what version of ser? Could you send me the output of uname -m and a backtrace (gdb ser core.* and then bt)?
Andrei
Its an Athlon 64 3400+ system with 512MB of RAM.
[root@sip1 ser]# uname -a Linux sip1 2.6.8-1.521 #1 Mon Aug 16 09:01:00 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux
I had to modify lock_ops.h on line 66 to include the following otherwise it would fail to compile: #include <errno.h> #include "dprint.h"
I would do the backtrace but ser doesn't seem to be generating a core file. Is there some sort of option to make it do that?
----------------------------------------
Michael Shuler, C.E.O. BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP) 682 High Point Lane East Peoria, IL 61611 Office: (217) 585-0357 Cell: (309) 657-6365 Fax: (309) 213-3500 E-Mail: mike@bwsys.net Customer Service: (877) 976-0711
-----Original Message----- From: Andrei Pelinescu-Onciul [mailto:pelinescu-onciul@fokus.fraunhofer.de] Sent: Tuesday, September 21, 2004 3:28 PM To: Michael Shuler Cc: serusers@lists.iptel.org Subject: Re: [Serusers] SER segfault on 64 bit
On Sep 21, 2004 at 14:27, Michael Shuler mike@bwsys.net wrote:
For some reason SER won't load on my 64 bit Fedora Core 2
machines but it
will work fine on all of my other 32bit Fedora Core 2
machines. Anyone know
if this a known problem with SER? I haven't been able to
find any info on
it so I'm guessing I'm just doing something wrong. Any
help would be
appreciated.
What kind of 64 bit machine are you using and what version of ser? Could you send me the output of uname -m and a backtrace (gdb ser core.* and then bt)?
Andrei
On Sep 21, 2004 at 17:02, Michael Shuler mike@bwsys.net wrote:
Its an Athlon 64 3400+ system with 512MB of RAM.
[root@sip1 ser]# uname -a Linux sip1 2.6.8-1.521 #1 Mon Aug 16 09:01:00 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux
I had to modify lock_ops.h on line 66 to include the following otherwise it would fail to compile: #include <errno.h> #include "dprint.h"
Try the latest unstable cvs and see also:
http://lists.iptel.org/pipermail/serdev/2004-September/002860.html http://lists.iptel.org/pipermail/serdev/2004-September/002862.html
Support for x86_64 is in a very early experimental stage (I don't have yet a machine to test it, so I can only suggest changes and see what happens).
I would do the backtrace but ser doesn't seem to be generating a core file. Is there some sort of option to make it do that?
You have to make sure your limits allow core dumping (ulimit -c unlimited) and that ser is allowed to dump core in the working directory (if you started it in the no fork mode), or in the dir. specified in the -w option. Also core dumping won't work on linux if you try to make ser suid to another user ( e.g.: ser -u nobody).
Andrei
Tell you what, we can pass debug stuff back and forth all day or I can just give you a shell account on the server. Let me know if you have any interest in this. Also your email server has my email server blacklisted for whatever reason. Until my techs get that resolved do you have an alternate email we can discuss this off list on?
----------------------------------------
Michael Shuler, C.E.O. BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP) 682 High Point Lane East Peoria, IL 61611 Office: (217) 585-0357 Cell: (309) 657-6365 Fax: (309) 213-3500 E-Mail: mike@bwsys.net Customer Service: (877) 976-0711
-----Original Message----- From: Andrei Pelinescu-Onciul [mailto:pelinescu-onciul@fokus.fraunhofer.de] Sent: Wednesday, September 22, 2004 6:49 AM To: Michael Shuler Cc: serusers@lists.iptel.org Subject: Re: [Serusers] SER segfault on 64 bit
On Sep 21, 2004 at 17:02, Michael Shuler mike@bwsys.net wrote:
Its an Athlon 64 3400+ system with 512MB of RAM.
[root@sip1 ser]# uname -a Linux sip1 2.6.8-1.521 #1 Mon Aug 16 09:01:00 EDT 2004
x86_64 x86_64 x86_64
GNU/Linux
I had to modify lock_ops.h on line 66 to include the
following otherwise it
would fail to compile: #include <errno.h> #include "dprint.h"
Try the latest unstable cvs and see also:
http://lists.iptel.org/pipermail/serdev/2004-September/002860.html http://lists.iptel.org/pipermail/serdev/2004-September/002862.html
Support for x86_64 is in a very early experimental stage (I don't have yet a machine to test it, so I can only suggest changes and see what happens).
I would do the backtrace but ser doesn't seem to be
generating a core file.
Is there some sort of option to make it do that?
You have to make sure your limits allow core dumping (ulimit -c unlimited) and that ser is allowed to dump core in the working directory (if you started it in the no fork mode), or in the dir. specified in the -w option. Also core dumping won't work on linux if you try to make ser suid to another user ( e.g.: ser -u nobody).
Andrei
-
Andrei Pelinescu-Onciul -
Michael Shuler