[email protected] wrote:
> Dave Shield wrote:
> Hi Dave,
>
> yes - this seems to work for the repeated snmpwalk tests (no failures
> after 40 tests - previously got one every 5-15 tests). The original
> application will have to run for 9 hours before I can verify th
Dave Shield wrote:
> Good catch!
> Try the following tweak to the code, and see if it fixes the problem:
>
>> 419 if (netsnmp_ds_get_boolean(NETSNMP_DS_LIBRARY_ID,
>> NETSNMP_DS_LIB_16BIT_IDS))
>> 420 retVal &= 0x7fff; /* mask to 15 bits */
>> 421 else
>> 422 retV
Bart Van Assche wrote:
> Can you please create a bug report with the information you posted on
> the Net-SNMP coders mailing list, and also the messages printed by
> Valgrind, including the "Address ... is ... bytes inside a block of
> size ... alloc'd" information ? See also
> https://sourcef
Bart Van Assche wrote:
> On Thu, Aug 6, 2009 at 12:02 PM,
>> Any opinions of whether this error could be causing my glibc double free
>> errors, or whether it is a red-herring?
>
> It is unlikely that the above message printed by Valgrind is related
> to the double free reported by glibc.
>
Bart Van Assche wrote:
> On Thu, Aug 6, 2009 at 12:02 PM,
> [email protected] wrote:
>> The 1 remaining valgrind error (reproduced at the end in full) is
>> complaining about
>>
>> "socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)&q
Bart Van Assche wrote:
> On Tue, Aug 4, 2009 at 4:06 PM,
> [email protected] wrote:
>> I have an application using net-snmp 5.4.2.1 which after some time -
>> seemingly proportional to the number of snmp requests - will terminate
>> with a glibc double free error.
Bart Van Assche wrote:
> On Tue, Aug 4, 2009 at 4:06 PM,
> [email protected] wrote:
>> I have an application using net-snmp 5.4.2.1 which after some time -
>> seemingly proportional to the number of snmp requests - will terminate
>> with a glibc double free error.
Hi,
I have been trying to solve an annoying problem for a couple of months
now - so was wondering if anyone has some fresh ideas or pointers on
what to try next.
I have an application using net-snmp 5.4.2.1 which after some time -
seemingly proportional to the number of snmp requests - will te
