14 Feb
2019
14 Feb
'19
12:47 a.m.
On 13.02.19 22:24, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
That patch was backported (at least to branch 5.2).
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 corrupted/overwritten. However, from the moment of
setting the variable till the moment of the crash, there are no other
set or copy operations, therefore nothing that I can relate to
kamailio's c code. Maybe it happens another time and the backtrace will
be different.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC,
USA -- www.asipto.com
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=&t->uac[branch];
An address of a variable (or field in a structure) cannot be null. Some
something happened with the stack. Did the OS kept running smooth after
this issue?
The OS is running smoothly all the time. It is possible to ssh to
the
host, take packet traces, etc. during Kamailio freeze. This
freezing/recovery happens happening at the frequency of once in a few
days.
So at this moment, either the core file was
somehow corrupted/not
properly dumped or kernel process supervizer did something wrong on
resume after the freeze.
As I mentioned, the OS is running normally during
Kamailio freeze.
There are no safety checks that can be added.
Maybe you can try to
reproduce and see if the new corefile gives a different backtrace.
Crash has
happened only once after the freeze. I'll let you know if
another crash happends and dump becomes available.
Could this freezing be caused by same kind of thing as the rtpengine
non-availability freeze that you fixed in master? If I remember
correctly, the fix was not backported to stable.