Short update: I think I found the issue and tried to come up with a
solution in the commit:
-
https://github.com/kamailio/kamailio/commit/814d5cc1f4f5b1e4b95737108dffc1e7d7bd566f
The tests that reproduced the crash rather quickly before the commit
(done by Yufei Tao) are now running fine for
Juha Heinanen writes:
> It was Debian Stretch installed on (if I remember correctly) xen virtual
> machine. I'll check to be sure.
Yes, it was VM on XenServer.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel-Constantin Mierla writes:
> Can you tell what linux distro and version was running in your case?
> Also, can you give the output for:
It was Debian Stretch installed on (if I remember correctly) xen virtual
machine. I'll check to be sure.
-- Juha
Today there was another report with a backtrace like the one you
reported, so I try to figure out if there are any common aspects between
the two systems.
Can you tell what linux distro and version was running in your case?
Also, can you give the output for:
uname -a
Cheers,
Daniel
On 14.02.19
Daniel-Constantin Mierla writes:
> However, that had invalid access to transaction pointer. In this case,
> accessing transaction is ok, by setting a variable to the address of one
> of its fields, but then the variable becomes NULL, which is not possible
> unless the stack got
On 13.02.19 22:24, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> replying to the initial message to have the backtrace easy to look at
>> its content...
>>
>> The info locals in frame 0 show:
>>
>> uac = 0x0
>>
>> However, that is set few lines above as:
>>
>> uac=>uac[branch];
>>
Daniel-Constantin Mierla writes:
> replying to the initial message to have the backtrace easy to look at
> its content...
>
> The info locals in frame 0 show:
>
> uac = 0x0
>
> However, that is set few lines above as:
>
> uac=>uac[branch];
>
> An address of a variable (or field in a
Hello,
replying to the initial message to have the backtrace easy to look at
its content...
The info locals in frame 0 show:
uac = 0x0
However, that is set few lines above as:
uac=>uac[branch];
An address of a variable (or field in a structure) cannot be null. Some
something happened with
Daniel-Constantin Mierla writes:
> OK. It happens to be traveling for few days, once I am back, I will dig
> into it and see how to fix this long delayed processing so it does not
> crash.
Thanks for looking into this. Perhaps the freeze is due to some locking
issue like the one when K didn't
OK. It happens to be traveling for few days, once I am back, I will dig
into it and see how to fix this long delayed processing so it does not
crash.
Cheers,
Daniel
On 06.02.19 22:04, Juha Heinanen wrote:
> I got the full syslog and pcap and based on those K indeed totally froze
> for about 14
I got the full syslog and pcap and based on those K indeed totally froze
for about 14 minutes. Below is updated summary:
- K receives INVITE at 17:43:28 and forwards it over udp to uas
- uas immediately responds with 183 followed by 180, which k forwards to UAC
- at 17:44:29 uas responds again
Daniel-Constantin Mierla writes:
> OK. There should be no crash no matter what caused the delay. I wanted
> to sort out the freezing of entire kamailio for 15min, because that is
> rather unusual to happen for all processes and then recover.
>
> I will look more at the tm for this delay/blocking
On 06.02.19 09:51, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> Thanks. I don't think that this is db related issue. Here is a
>> summary:
>>
>> - K receives INVITE at 17:43:28 and forwards it over udp to uas
>> - uas immediately responds with 183 followed by 180, which k forwards to UAC
Juha Heinanen writes:
> Thanks. I don't think that this is db related issue. Here is a
> summary:
>
> - K receives INVITE at 17:43:28 and forwards it over udp to uas
> - uas immediately responds with 183 followed by 180, which k forwards to UAC
> - at 17:44:29 uas responds again with 180 and K
Daniel-Constantin Mierla writes:
> It is rather strange that it got like "frozen" for 15 minutes. Was there
> a high CPU during that interval?
CPU was not high and that top showed nothing unusual during the freeze.
Also, there was nothing special in MySQL logs.
> Typically, if there is a
It is rather strange that it got like "frozen" for 15 minutes. Was there
a high CPU during that interval?
Typically, if there is a deadlock that block processing, then it does
not recover until restart. But in this case is no restart, because that
destroys active trasactions and no CANCEL would
Daniel-Constantin Mierla writes:
> I'll look into it. Was there a possibility that some operation could
> have taken very long, for example writing accounting database record?
Thanks. I don't think that this is db related issue. Here is a
summary:
- K receives INVITE at 17:43:28 and forwards
Hello,
I'll look into it. Was there a possibility that some operation could
have taken very long, for example writing accounting database record?
Cheers,
Daniel
On 05.02.19 11:00, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> pcap shows that kamailio receives from the uas two "180 ringing"
Juha Heinanen writes:
> pcap shows that kamailio receives from the uas two "180 ringing" replies
> 30 secs apart after which fr_inv_timeout hits. at that point kamailio
> sends "408 request timeout" to uac and gets back ack. then 45 secs
> later, kamailio gets one more "180 ringing" reply from
Juha Heinanen writes:
> Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is
> backtrace from the core file.
>
> The crash happens in t_reply.c on the last line of this block:
>
> uac=>uac[branch];
>
>
Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is
backtrace from the core file.
The crash happens in t_reply.c on the last line of this block:
uac=>uac[branch];
LM_DBG("org. status uas=%d, uac[%d]=%d local=%d
21 matches
Mail list logo
