Hello,
you will have to read the manual of the compiler and the specifics of
the operating system to build it without 64b alignment requirements. I
attempted to find it on the web, bit it may have not been the right one.
Cheers,
Daniel
On 6/28/12 5:45 AM, Akan wrote:
Daniel,
i did a repull
Hello,
for solaris sparc64 you have to find the option for compiler not to
build with strict alignment requirement for structures. I checked
quickly on the web in some man pages, but I am not sure I got the right
solution (what I previously sent on this thread).
If anyone can allocate resour
I tried in solaris the version kamailio 3.3.0 Bus error. For solaris I have had
that same issue in any version above the 1.4.3.
If i test in Suse, kamailio crashes when the radius or Diameter module is
enabled. this i tested with versions 3.1 3.2 i am checking if i can get the gdb
for all this.
Just to let you know
I made a lot of tests using different modules including carrierroute, I do have
the bus error also after the first call and core dump.
thank you
O
On Jun 27, 2012, at 11:45 PM, Akan wrote:
> Daniel,
>
> i did a repull from git, compiled, installed and re-test of Kama
Daniel,
i did a repull from git, compiled, installed and re-test of Kamailio and
got the same error in the same program's location as previous (in
tm_funcs.c). Here are the commands that I entered to make sure I did
everything correctly:
mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignm
Hello,
thanks for troubleshooting further -- as I expected, it is a memalign
problem, but some confusing reports by not using always the patches I
made to registrar module to align the structure, made thinking is
something else. Now is no longer in registrar, but in another module.
There mig
Hello,
After doing some research, this is what I found out. On Solaris Sparc
64bit system, there is a mandatory alignment of memory accesses and also
for data types. I went thru the core dump, disassembled the code and
located the instruction that produced the error. The registers addresses
i
I tested the patch and got different results. A core dump was still
produced but in a different program. I have included the full backtrace.
Thanks
Nathaniel
On 6/12/2012 1:10 PM, Akan wrote:
Yes, this is a 64bit system
Thanks
Nathaniel
On 6/12/2012 1:50 AM, Daniel-Constantin Mierla wrot
Yes, this is a 64bit system
Thanks
Nathaniel
On 6/12/2012 1:50 AM, Daniel-Constantin Mierla wrote:
Hello,
is it 64bit architecture?
Cheers,
Daniel
On 6/11/12 9:12 PM, Akan wrote:
Here is the information requested:
System = SunOS
Node = -f
Release = 5.10
KernelID = Generic_141444-09
Machi
Yes, This is a 64bit system
T-Mobile. America’s First Nationwide 4G Network
Jason Penton wrote:
>from the logs he has sent the mem addresses all look 64 bit. Sparc AFAIK is
>only 64 bit anyway
>
>Cheers
>Jason
>
>On Tue, Jun 12, 2012 at 8:50 AM, Daniel-Constantin Mierla > wrote:
>
>> Hello,
>>
from the logs he has sent the mem addresses all look 64 bit. Sparc AFAIK is
only 64 bit anyway
Cheers
Jason
On Tue, Jun 12, 2012 at 8:50 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> is it 64bit architecture?
>
> Cheers,
> Daniel
>
>
> On 6/11/12 9:12 PM, Akan wrote:
>
>> Here is the informa
Hello,
is it 64bit architecture?
Cheers,
Daniel
On 6/11/12 9:12 PM, Akan wrote:
Here is the information requested:
System = SunOS
Node = -f
Release = 5.10
KernelID = Generic_141444-09
Machine = sun4u
BusType =
Serial =
Users =
OEM# = 0
Origin# = 1
NumCPU = 1
One machine is a Sun Fire V120
Here is the information requested:
System = SunOS
Node = -f
Release = 5.10
KernelID = Generic_141444-09
Machine = sun4u
BusType =
Serial =
Users =
OEM# = 0
Origin# = 1
NumCPU = 1
One machine is a Sun Fire V120, 2g memory, UltraSPARC-IIe 650MHz, UltraAX-i2
The other machine is a Sun Netra T1
Hello,
I committed a patch that should make it work when realm_prefix is not
set for registrar module:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d42379da90f2ec87cb5dbb00ebb563c7528ec910
For the moment I have no idea why SIGBUS is triggered, i tried to access
the str
Hello,
I got access and it is actually gcc, here are the compile options:
$ gmake Q=0
Makefile.defs defs skipped
gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc
-fno-strict-overflow -ftree-vectorize -Wall-DNAME='"kamailio"'
-DVERSION='"3.3.0-pre3"' -DARCH='"sparc64"' -DOS
This seems like a really strange bug, what compiler are you using, gcc or
sun studio? We use gcc and don't have any issues like this. I will use sun
studio if you confirm that you are using it and will give that a go.
Cheers
Jason
On Mon, Jun 4, 2012 at 8:57 AM, Daniel-Constantin Mierla
wrote:
>
Hello,
still strange with the crash on that if condition. One of your previous
reports showed a different line, when assigning a pointer. Also, I kind
of understood that save() was ok, but lookup() not. Is not the case
anymore as the backtrace shows.
SIGBUS can occur because of alignment in
Ok, I reloaded the servers with v3.2 from git without performing the
checkout and with just the master branch. Reran my tests on 2 servers
and Kamailio terminated with a core dump. I have included the full trace
of one of the servers. The other trace has the same results.
Thanks
Nathaniel
O
Hello,
On 5/30/12 9:10 PM, Akan wrote:
This was a re-pull from the git master. I had deleted all of the old
files and issued these commands:
git clone --depth 1 git://git.sip-router.org/sip-router kamailio
cd kamailio
git checkout -b 3.2 origin/3.2
This is the source that I got. Could this be
This was a re-pull from the git master. I had deleted all of the old
files and issued these commands:
git clone --depth 1 git://git.sip-router.org/sip-router kamailio
cd kamailio
git checkout -b 3.2 origin/3.2
This is the source that I got. Could this be a problem within git?
Thanks
Nathaniel
Hello,
On 5/30/12 4:26 AM, Akan wrote:
Sorry. To make sure I got the right versions, I removed all of the
previous files, reloaded and re-compiled Kamailio from git and ran the
test again.
is it git master branch? Because the branch 3.2 does not have all
patches backported, as I wanted to test
Sorry. To make sure I got the right versions, I removed all of the
previous files, reloaded and re-compiled Kamailio from git and ran the
test again. I have included the full trace files from the core dump.
Here is my setting for use_domain parameter:
#!define MULTIDOMAIN 1
modparam("usrloc",
Hello,
is this with use_domain parameter set?
Also, from the backtrace, the condition is not
104 if (realm_prefix.len>0 && realm_prefix.lenIt looks it is without the last recommendation I made - now I pushed the
change also in master branch.
Cheers,
Daniel
On 5/29/12 10:
I'd setup another solaris server with kamailio v3.2, applied the patch
and tested the change. Kamailio did not crash nor took a core dump. So
it looks like it might be a hardware problem now.
Thanks
Nathaniel
On 5/9/2012 1:52 PM, Akan wrote:
I changed the use_domain parameter for usrloc to 0
I changed the use_domain parameter for usrloc to 0 and retried. Kamailio
did not crash and I was able to get registered. I have another server
with the same configurations as the one having the problem. I will apply
the patch there and see if the problem still occurs. Also, setting the
use_doma
Hello,
I see no reason why it crashes at line 104 when realm_prefix.len==0.
Might be a memory problem (hardware). Can you try with use_domain
parameter set to 0 for usrloc module?
Cheers,
Daniel
On 5/5/12 5:29 PM, Akan wrote:
I made the change and still have the problem. I have included the
I made the change and still have the problem. I have included the output
from stepping thru via gdb and the block of code where I made the change
and that was executed.
98 if (reg_use_domain) {
99 if (user_len)
100 aor_buf[_a->len++] = '
Hello,
interesting, it seems to crash at the evaluation of 'realm_prefix.len' -
because it is 0, the IF condition should stop evaluation of the rest of
the expression.
Can you try to change the first part of the condition at line 104 to:
if (realm_prefix.len>0 && ...
Cheers,
Daniel
On 5/4/
I was able to step thru via gdb to the point where Kamailio took a
segment fault. I have included a backtrace as well as the output from me
stepping thru common.c to the point where it failed. Hope this will help.
Thanks
Nathaniel
On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote:
Hello,
I applied the changes, reran the test and this time I got a core dump. I
have included the core dumps as attachments and listed the commands that
I used to apply the patches.
# git apply --check registrar-real-prefix-str.patch
# git apply registrar-real-prefix-str.patch
Thanks
Nathaniel
On 4
Hello,
the issue was a sig bus this time, which more enforced in sparc/solaris,
not common in linux. I was looked at the structure and seems aligned ok,
mis-alignment being the most often used to rise sigbus. What I could
think as next reason was the empty string default value which may make
I tried adding the realm_prefix and still got the same problem. I ran
kamailio thru gdb to try and step thru and get more information and have
included the output in the attached text file. Hope this helps.
Thanks
Nathaniel L Keeling
On 4/26/2012 2:42 PM, Akan wrote:
No, but I do have an ali
No, but I do have an alias defined.
alias="mydomain.com:5080"
Thanks
Nathaniel
On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:
Hello,
do you set the realm_prefix parameter of registrar module?
http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082
If yes, can you
Hello,
do you set the realm_prefix parameter of registrar module?
http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082
If yes, can you paste it here?
Cheers,
Daniel
On 4/25/12 9:42 PM, Akan wrote:
I have 2 servers running Solaris and Kamailio 3.2.3 where on one
Kamailio
I have 2 servers running Solaris and Kamailio 3.2.3 where on one
Kamailio is terminating when it tries to save the location for a
register request and the other is producing a core dump when processing
an Option request. I have one server handling Register request while the
other sip server for
35 matches
Mail list logo
