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
On Oct 15, 2009 at 15:53, Juha Heinanen jh@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
On Thu, Oct 15, 2009 at 3:49 PM, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
> 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.
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
On Oct 15, 2009 at 16:49, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
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.
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
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
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
On Oct 15, 2009 at 18:21, Juha Heinanen jh@tutpro.com wrote:
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.
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
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
On Oct 15, 2009 at 17:54, Juha Heinanen jh@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
-
Andrei Pelinescu-Onciul -
Jan Janak -
jh＠tutpro.com -
Juha Heinanen