I looked a bit at the code and $du is not considered anymore, because the next
hop address is computed by the c function executed by various modules that send
local requests. The event route is executed later, when the transaction
structure is already created.
So drop and considering new $du ma
without pua_reginfo
REGISTER
```
Feb 17 09:40:56 sp1 proxy[25182]: NOTICE:
Your comments are quite minimalistic and didn't have time to look deeper at
this potential issue. Are you saying that the issue is triggered by pua_reginfo?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/
We use registrations with dbmode =3 with no problems and we don't use
pua_reginfo
On Friday, February 17, 2017, Daniel-Constantin Mierla <
notificati...@github.com> wrote:
> Your comments are quite minimalistic and didn't have time to look deeper
> at this potential issue. Are you saying that the
Yes, the problem is happening for me because of pua_reginfo and I did
https://github.com/linuxmaniac/kamailio/commit/2152b8c3ad4b1d61c4a456f7cb082ccfd10fe39c
in order to solve it. But even with that I still get ucontac at shared mem
left.
I'm suspecting that the underlying problem is the combin
I would suggest as possible solutions:
- remove the ``get_static_urecord()`` and the use proper reserved memory for
``urecord`` and free that
at ``release_urecord()``
- keep a copy of ``urecord`` before calling ul_callbacks so we can safely free
the ``ucontact`` afterwards
Being the second the
As release_urecord() clearly says:
/*!
* \brief Release urecord previously obtained through get_urecord
* \warning Failing to calls this function after get_urecord will
* result in a memory leak when the DB_ONLY mode is used. When
* the records is later deleted, e.g. with delete_urecord, then
Is the PR #998 implementing the second option you suggested above?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/997#issuecomment-280609876
No. #998 is implementing the missing ``release_urecord()`` after
``get_urecord()`` call.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/997#issuecomment-280610168_
So there is still going to be an issue after merging #998? Or that's the
complete fix for the problem?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/997#issuecomment-280610599___
There will be still an issue after merging #998 but the situation will
improved, there will be less leaks.
without the patch in a REGISTER/UPDATE REGISTER/UNREGISTER scenario I get left
```
Feb 17 11:20:52 sp1 proxy[12364]: NOTICE: fm_status: count=30 size=
1416 bytes from usrloc: ../
Should I start working on the solution second solution? Is that the best
approach?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/997#issuecomment-280615776___
## Motivation
1. DOC says `setid` in mysql should be `UNSIGNED INT`:
http://www.kamailio.org/docs/modules/4.4.x/modules/rtpengine.html#rtpengine.p.table_name
http://www.kamailio.org/docs/modules/4.4.x/modules/rtpengine.html#rtpengine.p.setid_col
2. kamailio did report invalid value if
keep a copy of ``urecord`` if mode is DB_ONLY as it is static preventing
leaking ``ucontact`` to shared memory
See #997 for details
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1000
-- Commit Summary --
* usrloc: fix ucontact sha
Yes I think you're right. It should use `str2int` instead of `str2s`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/999#issuecomment-280645183___
With #998 and #1000 applied and some debug
REGISTER
```
Feb 17 14:03:55 sp1 proxy[22494]: NOTICE:
Hi,
We've noticed a case where the *location_attrs* table isn't updated when
there's an unexpected shutdown of a SIP device (here there'll be no
REGISTER message sent with expires=0).
We're using Kamailio v4.3.x
When the SIP device shuts down ungracefully. The location table is updated
using DEL
### Description
pkg memory leak in register/publish scenario
Reproduction
my presense part
```
loadmodule "presence.so"
modparam("presence", "subs_db_mode", 2) # Write-Back default scheme
modparam("presence", "db_update_period", 150) # 100 - default
modparam("presence", "server_address",
Was the pid 10376 printing memory allocation errors? Because the log with pkg
summary doesn't show a leak, there are only few hundreds of chunks, which are
allocated at startup, not at runtime.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Closed #965.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/965#event-967515903___
sr-dev mailing list
sr-dev@lists.sip-router.org
http:
There is a flag that can be set to trace outgoing requests as well.
In latest stable, 4.4, there is an option to trace everything without making
use of flags.
If you have more questions about using it, then write to sr-users mailing list.
The tracker here is used for bug reports and feature req
Can this be closed? It's getting quite old, or there are new details to be
considered.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/807#issuecomment-280754573___
Feb 17 21:12:00 sw5 /usr/local/dev_kamailio/sbin/kamailio[10376]: ERROR:
[core/mem/q_malloc.c:292]: qm_find_free(): qm_find_free(0x7f45a3ff2010, 688);
Free fragment not found!
Feb 17 21:12:00 sw5 /usr/local/dev_kamailio/sbin/kamailio[10376]: ERROR:
[core/mem/q_malloc.c:425]: qm_malloc(): qm_ma
If it helps, we use presence heavily and do not see this. However... we don't
use the database implementation because it's never worked properly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/ka
24 matches
Mail list logo
