15 Oct
2009
15 Oct
'09
3:53 p.m.
i build new sip-router and then tried to make a call, but the request
that sr send out contained binary garbage in the header section after
append_hf call. i have two append_hf calls and garbage is after the
header added by the first call. the second header is not there at all,
but just garbage.
has something changed during the previous couple of days that could
explain this?
-- juha
15 Oct
15 Oct
4:40 p.m.
On Oct 15, 2009 at 15:53, Juha Heinanen <jh(a)tutpro.com> wrote:
i build new sip-router and then tried to make a call,
but the request
that sr send out contained binary garbage in the header section after
append_hf call. i have two append_hf calls and garbage is after the
header added by the first call. the second header is not there at all,
but just garbage.
has something changed during the previous couple of days that could
explain this?
Here are the changes in the last 2 days:
master:
git log --oneline origin/master@"{2 days ago}"..origin/master
41ed930 Remove reference to the tool gen_ha1 from packaging file.
fade70e Remove obsolete gen_ha1.
41273f9 Fix test 21.sh Module path problems
233fb50 Merge branch 'master' of ssh://oej@git.sip-router.org/sip-router
83d1171 - Doxygen updates - Reinstalling README
2b9b87a Typos, small updates
22595b7 tls(sr): fix define error introduced in 9accd256fdc80e6a6207cb7
a342195 Test 20.sh fixed Fixed module loading Checked contact data into
aae7a8f Test 19 Fixed tm loading order Fixed path of ser executable
2b6a11b Fixed path of ser exacutable in test(18.sh) Improved cleaning of
2605ea2 Fix path for dbtext
9e9f438 Fixed loading of tm module in test Fixed variable name ($fU
sr_3.0:
git log --oneline origin/sr_3.0@"{2 days ago}"..origin/sr_3.0
e79a572 Remove obsolete gen_ha1.
9af70ff modules_k/permissions: Increased version number of 'trusted'
table
959b95f lib/srdb1/schema/trusted.xml: forgot to increase version number
0312ea0 lib/srdb1/schema/trusted.xml: increased tag length from 32 to 64
chars
8421aeb makefile: support self-installing utils, extra cfgs a.s.o.
af8f3e1 core: fix memleak in fixup_free*
Which branch are you using?
Did the same config work a few days ago?
Andrei
5 p.m.
On Thu, Oct 15, 2009 at 3:49 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
I don't know if it helps, but you may want to try to use git-bisect to
find the commit which causes the problem. See man git-bisect for
details and examples.
I haven't tried to use this on the sip-router repository yet so I
cannot give you an exact example.
-- Jan
Which branch are you using?
Did the same config work a few days ago?
branch is sr_3.0 and the one that i built on oct 12 works ok. the one
that i build today, generates garbage. i don't remember making any
changes in config file.
5:05 p.m.
On Oct 15, 2009 at 16:49, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
The only changes that might be relevant since 12 Oct are
af8f3e1 core: fix memleak in fixup_free*
and gcc warning fixes ing userblacklist, statistics, siputils,
registrar, pua_mi, cfgutils, lcr, db_mysql, db_postgres.
The append_hf() that fails is from textops(k) or textops(s)?
Is it accessed directly or via an api from another module?
Is it easy to reproduce?
What modules do you have loaded?
Andrei
Which branch are you using?
Did the same config work a few days ago?
branch is sr_3.0 and the one that i built on oct 12 works ok. the one
that i build today, generates garbage. i don't remember making any
changes in config file.
5:54 p.m.
andrei,
i looked again your core: fix memleak in fixup_free* commit and there
you say:
It should have no impact, since at this point nobody seems to use
any fixup_free* functions.
what do you mean by that, because there are many sr and k modules that
use various fixup_free functions?
-- juha
6:21 p.m.
Juha Heinanen writes:
what do you mean by that, because there are many sr
and k modules that
use various fixup_free functions?
i went and reverted this sr_module.c commit. after that the garbage
that i have been seeing in outgoing sip request disappeared.
so this patch definitely has something to do with the problem.
-- juha
7:16 p.m.
On Oct 15, 2009 at 18:21, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
Yes, it did have something to do with it: turns out the fixup_spve*
functions wrongly freed the contents of a fixed spve, which included the
original string. You did not see the bug before, because the original
string was not freed (memleak).
It should be fixed now.
Andrei
what do you mean by that, because there are many
sr and k modules that
use various fixup_free functions?
i went and reverted this sr_module.c commit. after that the garbage
that i have been seeing in outgoing sip request disappeared.
so this patch definitely has something to do with the problem.
7:23 p.m.
Andrei Pelinescu-Onciul writes:
Yes, it did have something to do with it: turns out
the fixup_spve*
functions wrongly freed the contents of a fixed spve, which included the
original string. You did not see the bug before, because the original
string was not freed (memleak).
It should be fixed now.
thanks andrei, no garbage anymore.
-=- juha
7:14 p.m.
On Oct 15, 2009 at 17:54, Juha Heinanen <jh(a)tutpro.com> wrote:
andrei,
i looked again your core: fix memleak in fixup_free* commit and there
you say:
It should have no impact, since at this point nobody seems to use
any fixup_free* functions.
what do you mean by that, because there are many sr and k modules that
use various fixup_free functions?
No, there aren't any.
The only functions that call a free_fixup* are search_append_api()
and search_api() from textops_k and they aren't called by any module on
the repository at this time.
Some k modules register fixup_free_* functions in their cmd_exports, but
nobody calls them ever (I understood the reason for them was the perl
module, which is no longer maintained).
In the future I was thinking of calling them at shutdown time, to get
nicer memory status, but I refrained to add this now because of the
release.
Andrei
5518
days inactive
5518
days old
9 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Jan Janak -
jh＠tutpro.com -
Juha Heinanen