The bug occurs when a query is being executed with usage of parameters array where array is empty. Something along the lines of
connection.query('SELECT 1;', [], function (err, result) { ... });
In such cases, ODBC::GetParametersFromArray is being executed and since values->Length() is equal to 0, the call to malloc effectively becomes malloc(0). Behavior of such call is not strictly defined. C99 standard states that either a null pointer should be returned or the call should behave as if the requested size was nonzero and a unique pointer is returned with the exception that the address should not be accessed (PDF Warning - ISO/IEC 9899:TC2, section 7.20.3, page 313).
The actual cause of the leak is the fact that in all instances where the parameter array returned by ODBC::GetParametersFromArray is freed, it is only done under condition that there were more than 0 parameters in the query - example.
Given enough time and enough queries, those several lost bytes did pile up.
The bug occurs when a query is being executed with usage of parameters array where array is empty. Something along the lines of
In such cases,
ODBC::GetParametersFromArray
is being executed and sincevalues->Length()
is equal to 0, the call tomalloc
effectively becomesmalloc(0)
. Behavior of such call is not strictly defined. C99 standard states that either a null pointer should be returned or the call should behave as if the requested size was nonzero and a unique pointer is returned with the exception that the address should not be accessed (PDF Warning - ISO/IEC 9899:TC2, section 7.20.3, page 313).As it stands,
glibc
displays the latter behavior, additionally defining a minimum allocated size.The actual cause of the leak is the fact that in all instances where the parameter array returned by
ODBC::GetParametersFromArray
is freed, it is only done under condition that there were more than 0 parameters in the query - example.Given enough time and enough queries, those several lost bytes did pile up.