[OpenSIPS-Devel] SF.net SVN: opensips:[5847] trunk/modules/nat_traversal/nat_traversal.c

[Thomas Gelf]

Dan Pascu wrote:
> Just to get an idea why the case Thomas gets is so unexpected, contact- 
>  >uri is built using this code:
> 
> static char*
> get_source_uri(struct sip_msg *msg)
> {
>      static char uri[64];
>      snprintf(uri, 64, "sip:%s:%d", ip_addr2a(&msg->rcv.src_ip), msg- 
>  >rcv.src_port);
>      return uri;
> }
> 
> and then duplicated in shared memory. There is no way for contact->uri  
> to end up NULL or not to contain the IP and port, no matter what  
> actions the user does in the script.

Is this also true if I'm doing AVP_RECEIVED = $source_uri ?
(that's what my config looks like)

> Right now I suspect that Thomas suffers from some sort of memory  
> corruption that happens to affect the nat_traversal module internal  
> data somehow.
> 
> Thomas, can you please compile opensips to use the system malloc  
> instead of pkg_malloc and see if the problem persists? I had suffered  
> similar weird memory corruption issues in the past, that could not be  
> identified but were cured by using the system malloc. In my case the  
> segfaults happened in t_relay or sl_send_reply, but the memory was  
> similarly corrupted in unexpected places.

I did so - or better, I tried my best to do so. Changes in revision
5653 didn't allow me to compile with system malloc. At least that's
my assumption. As I never wrote a C program that's just a wild guess.
After reverting some changes (r5653-5655) and disabling STATISTICS
I have finally been able to compile without PKG_MALLOC (see other
thread).

I do not really like the idea to reproduce the nat_helper crash, as
I have (very) few customers already using this proxy. And I really
have no idea how to do so. It was a really strange effect - after
a restart it kept crashing and crashing. After a while it appeared
to be stable again - but after the next call (not sure if it was
really the next one) - it crashed and crashed once again. Usually
it did so shortly after a new dialog started (at least it seemed
to be so). If you'd like to have a look at the core files I could
try to find the corresponding binary.

However, I discovered other ways to crash OpenSIPS - and they still
work even with my somehow-fiddled-system-malloc-version. I'll send
another post with related information.

There is one thing I got aware of: shortly after being started it's
easy to produce crashes - if running without being disturbed for a
while chances are good that it will keep running. I know that this
is not a good diagnose - but that's how it seemed to behave. OpenSIPS
probably needs a lot of love and care ;-)

Best regards,
Thomas Gelf