@razvancrainea yes, we had the issue maybe every hour or so (on one server) on
the day it first appeared (we also had it on other servers with a lesser rate).
I hadn't done much work with the internals of OpenSIPS so didn't know about the
memory debugging allocator, and since it was a SIGSEGV I first tried to figure
out where the crash was happening; it's only later that I figured out that the
memory allocator was involved and that the actual issue might be incorrect use
of the allocator.
We had some low-rate unwanted traffic on those servers while this was happening
(INVITEs, with no ACKs) and the problems kind-of disappeared after I blocked
the IPs that were causing trouble; however I can't say for sure this was the
source of the problem; either way this might be difficult to re-create.
Following up on @liviuchircu 's note, the only `CRIT`-level notices I see on
the new versions (with #722 applied, running over the week-end) are
`CRITICAL:tm:set_timer: set_timer for 1 list called on a "detached" timer --
ignoring`.
→ Do I need to set `memlog=1` for this to work?
I'll see if I can build a test image with the memory allocator and put it
alongside the production images.
→ should I use the QM allocator (`DBG_QM_MALLOC`), or is it enough to use
`DBG_F_MALLOC` ?
I guess I could also `abort()` at the point in the allocator where the problem
is detected.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/721#issuecomment-164458308
_______________________________________________
Devel mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
