hello Daniel
yes yes i understood.
thanks a lot
david
El mar, 28-03-2017 a las 13:44 +0200, Daniel-Constantin Mierla
escribió:
> Hello,
>
> it is already backported to branch 4.4 -- I said that you can use
> latest 4.4 branch from git -- backporting was only if you want to
> still use 4.4.1
Hello,
it is already backported to branch 4.4 -- I said that you can use latest
4.4 branch from git -- backporting was only if you want to still use
4.4.1 snapshot + this patch.
Therefore next release in 4.4 series will have it as well.
Cheers,
Daniel
On 28/03/2017 13:42, David Escartín
hello Daniel
thanks a lot.
we actually will start testing 5.0 to migrate to it, but in the meantime
it's great if we can patch it on the 4.4
best regards
david
El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió:
> Hello,
>
> I pushed a safety checks to avoid crash in
Hello,
I pushed a safety checks to avoid crash in this situation. I will have
to investigate deeper why it got to this state, but for now the fix
should avoid this crash in a similar situation. You have to use the
latest branch 4.4 or backport the patch
e20b38e0084c1f89c43a921a8a2affbea060aaa5 to
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself
but i couldnt create the sipp scenario
i will try to duplicate it setting the octal parameters in hex escaped
by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers,
Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
> hello Daniel
>
> here you have
>
> (gdb) frame 1
> #1 0x0045b472 in _dns_hash_find
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an
older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers,
Daniel
On 24/03/2017 14:50, David
hello all, Daniel
checking the core with the gdb, we have checked the variables at the
frames of the backtrace, to try to get the full sip message seems it
seemed truncated.
checking the buf variable of the frame 11 which theorically contains the
sip msg to parse we have the string
SIP/2.0 487
hello all
we have experienced a crash and tracing the logs and the core, seems it
was because a sip response from an endpoint.
a UDP receiver (26248) crashed and the last message we see on it is a
487 quite bad formed
Mar 24 01:58:02
mia-proxy-inout-1-stby
