[SR-Users] Fwd: pv_buffer_size config value actually ignored?

Enrico Bandiera enrico.bandiera at cloud.timenet.it
Wed Feb 13 17:29:45 CET 2019


Hello Daniel, here are the logs:

29(46) ERROR: <core> [core/pvapi.c:1457]: pv_printf(): no more space for
spec value - printed:7 token:5131 buffer:4096
29(46) ERROR: <core> [core/pvapi.c:1467]: pv_printf(): buffer overflow --
increase the buffer size...
29(46) ERROR: <core> [core/pvapi.c:1457]: pv_printf(): no more space for
spec value - printed:7 token:5129 buffer:4096
29(46) ERROR: <core> [core/pvapi.c:1467]: pv_printf(): buffer overflow --
increase the buffer size...

Thanks,
Enrico


Il giorno mer 13 feb 2019 alle ore 09:45 Daniel-Constantin Mierla <
miconda at gmail.com> ha scritto:

> Hello,
>
> I pushed a patch to print more details about printed size, current token
> size and overall output buffer size in those error log messages -- the
> commit:
>
>   *
> https://github.com/kamailio/kamailio/commit/44e48809a608d4de46d61198137cd669c6a4763f
>
> Can you try with this patch and send again here on mailing list the error
> log messages?
>
> Cheers,
> Daniel
> On 13.02.19 09:20, Enrico Bandiera wrote:
>
>
>
> ---------- Forwarded message ---------
> From: Enrico Bandiera <enrico.bandiera at cloud.timenet.it>
> Date: mer 13 feb 2019 alle ore 09:18
> Subject: Re: [SR-Users] pv_buffer_size config value actually ignored?
> To: Daniel-Constantin Mierla <miconda at gmail.com>
>
>
> Hello Daniel, yes we do use that $avp for a log line which is actually a
> big json, the $avp is composed by multiple jansson_append calls and at the
> end an xlog() calls prints it
> Could it also be that I'm miscalculating because of the encoding? 4K utf8
> characters could be more than 4K (but I don't think there are so many
> multibytes characters to let it reach the 8K limit)
>
> Il giorno mer 13 feb 2019 alle ore 09:15 Daniel-Constantin Mierla <
> miconda at gmail.com> ha scritto:
>
>> Hello,
>>
>> where do you use that avp, because for the avp value itself, that buffer
>> is not used -- avp values are stored in shared memory.
>>
>> Do you use that avp in xlog() or other functions parameters?
>>
>> Cheers,
>> Daniel
>> On 13.02.19 09:10, Enrico Bandiera wrote:
>>
>> Hi, I'm having some strange issues with a somewhat big $avp value, when
>> it reaches a size of about 4K I get this error:
>>
>> 29(47) ERROR: <core> [core/pvapi.c:1452]: pv_printf(): no more space for
>> spec value
>> 29(47) ERROR: <core> [core/pvapi.c:1461]: pv_printf(): buffer overflow –
>> increase the buffer size...
>>
>> In the docs I read that the default pv_buffer_size is 8K, I still tried
>> to enforce it to something bigger and checked the logs to be sure it was
>> set:
>>
>> 0(384) DEBUG: <core> [core/pvapi.c:2062]: pv_init_buffer(): PV print
>> buffer initialized to [40][16384]
>>
>> But still when reaching the 4K size inside the $avp that error comes out,
>> is there any limit I'm not aware of?
>>
>> Thanks,
>> Enrico.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
>> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
>>
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190213/849f6b3b/attachment.html>


More information about the sr-users mailing list