On Sun, 2003-04-13 at 13:28, Tim Peters wrote: > It appears to be a refcount error in recently-added C code that tries to > generalize the builtin range() function, specifically here: > > Fail: > Py_XDECREF(curnum); > Py_XDECREF(istep); <- here > Py_XDECREF(zero); > > Word to the wise: don't ever try to reuse a variable whose address is > passed to PyArg_ParseTuple for anything other than holding what > PyArg_ParseTuple does or doesn't store into it. Hmm, then this is my fault. I did exactly that. My approach was to Py_INCREF an optional argument it if it was given (ie. not NULL), otherwise to create it from scratch, and Py_DECREF when I was done. I believe this was a not uncommon idiom (I can't recal the specifics, but being my first submitted patch, I made sure to try to look for existing idioms for argument and error handling). I apologize if I erred. I assume a better approach, then is to get the optional istep argument, and copy it into a variable for your own use (or create it if it didn't exist)? ie. Never increment or decrement the optional argument object, returned from PyArg_ParseTuple, at all? > You'll never get the > decrefs straight (and even if you manage to at first, the next person to > modify your code will break it). Bingo! Guido took a slightly different approach (and ultimately a better one, I think), in adapting my patch. Perhaps I unknowingly left a time bomb for him. I'll submit a patch to fix this all up tonight, if it hasn't already been addressed by then. > only-consumed-eight-hours-this-time<wink>-ly y'rs - tim Oh, ow! Now that pains me. I am very sorry to hear this wasted so much time. Chad Netzer
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4