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=&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.
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