Issue 145: cursor.execute leaks parameters
Status:  Complete
Owner: ----
Closed:  Sep 2011
Reported by lukedell...@gmail.com, Dec 16, 2010
The parameters to cursor.execute are being leaked.  This is really noticeable when INSERTing a lot of data.  The problem is due to PySequence_GetItem (which returns a *new* reference) being used on the parameter list to pick out each parameter, but this reference is never released.

A test case patch and a fix patch are attached.

pyodbc-paramleak-test.patch
964 bytes   View   Download
pyodbc-paramleak-fix.patch
2.6 KB   View   Download
Dec 22, 2010
#1 cy...@ikos.com.cy
I actually INSERT a lot of data, and found out this leak as well.
I cannot run the patch (not used to) and need to solve this issue.
Would you have another way to solve this?
May 12, 2011
#2 lamba...@gmail.com
I have applied this patch to current github trunk (7580498b9f8c8c7e08ad). It applies cleanly and fixes the memory leak.
Jun 18, 2011
#4 bsg...@gmail.com
Attempting to apply this patch to either the trunk or v2.1.8 on OS X results in errors:

patch < pyodbc-paramleak-fix.patch 

patching file cursor.h
patching file params.cpp
Hunk #1 FAILED at 20.
Hunk #2 FAILED at 457.
Hunk #3 FAILED at 567.
Hunk #4 FAILED at 647.
4 out of 4 hunks FAILED -- saving rejects to file params.cpp.rej

Jun 18, 2011
#5 lukedell...@gmail.com
This looks like a text file line ending issue.  I see that in git trunk & pyodbc-2.1.8.zip there is a mixture of Windows-style CR+LF line endings, and Unix-style LF line endings.  In this specific case cursor.h uses LF and so works fine for you, but params.cpp uses CR+LF and so you get these conflicts.  Not sure if I should adjust the patch to take this into account?  Meanwhile if you convert params.cpp to Unix-style LF line endings then the existing patch should work fine.
Jun 20, 2011
#6 bsg...@gmail.com
Normalizing line endings allows patch application, and the patch appears to resolve the memory leak.

 Issue 184  entered for the mixed line endings.
Jun 22, 2011
#8 bsg...@gmail.com
Verified that this patch resolves the leak, tested on Win64 and OS X 10.6. An ETL script with 38 hour average runs was consuming up to 30GB of RAM using parameterized inserts on unpatched 2.1.8

Applying the patch keeps memory consumption under 20MB for the same script.
Sep 12, 2011
Project Member #9 mkleehammer
I sincerely appreciate the fix!  I apologize for missed this earlier.

I've used the fix you suggested and am releasing 2.1.10 for this.


Status: Complete
Sep 13, 2011
#10 bsg...@gmail.com
Will you be adding a 64-bit Windows binary?

Sep 13, 2011
#11 bsg...@gmail.com
I was able to build on 64 bit Win2008, but I had to add the utils path to the source from git. It was not part of the source zip.