[SR-Users] Kamailio Unexpectedly Terminating

[Daniel-Constantin Mierla]

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 might be many of these, can you try to compile first without 
strict alignment to 8 bytes? Checking quickly to gcc, the option should 
be |-mno-faster-structs

So try:

make proper
make FLAVOUR=kamailio cfg|
make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
...

By providing Q=0, you will see all compile flags, verify that 
|-mno-faster-structs is there.

Cheers,
Daniel
|
On 6/22/12 3:26 PM, Akan wrote:
> 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 in questioned are on a 4 byte alignment but not an 8 byte or 
> 16 byte alignment. .The earlier patch must have forced the alignment 
> which is why the error did not occur in the program common.c. It looks 
> like there is a similar situation in t_funcs.c.
>
> Here is a link that I found that can better explain:
> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>
> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
> Program terminated with signal 10, Bus error.
> #0  0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, 
> proto=0, replicate=0) at t_funcs.c:352
> 352                     if (!t_reply( t, p_msg , 100 ,
>
>   0xffffffff7bd2b7b0 <+976>:   ldx  [ %l7 + %g1 ], %g1
>    0xffffffff7bd2b7b4 <+980>:   ldx  [ %g1 ], %g1
>    0xffffffff7bd2b7b8 <+984>:   call  0xffffffff7be9bc80 <t_reply at plt>
> *=> 0xffffffff7bd2b7bc <+988>:   ldx  [ %g1 + 0x38 ], %o3*
>    0xffffffff7bd2b7c0 <+992>:   cmp  %o0, 0
>    0xffffffff7bd2b7c4 <+996>:   be,pn   %icc, 0xffffffff7bd2bb14 
> <t_relay_to+1844>
>    0xffffffff7bd2b7c8 <+1000>:  ldx  [ %fp + 0x7f7 ], %o0
>    0xffffffff7bd2b7cc <+1004>:  b  %xcc, 0xffffffff7bd2b460 
> <t_relay_to+128>
>
> End of assembler dump.
> (gdb) info registers g1
> g1             0xffffffff7666c3e4       -2308520988
> (gdb) info registers o3
> o3             0x18f3d0 1635280
>
> I hope this helps in trying to resolve this problem and to find a 
> solution. Also, if you need a sparc system to test with, just let me 
> know. We can help from a sparc perspective.
>
> Thanks
>
> Nathaniel
>
>


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120625/41e94697/attachment.htm>