CJ Kucera wrote:
> Okay, I've got a reproducible testcase of this available up here:
> http://apocalyptech.com/pygtk-zlib/
>
> I'm no longer *totally* convinced that it's a zlib issue... zlib's call
> actually returns a valid string, and the error happens la
CJ Kucera wrote:
> Okay, I've got a reproducible testcase of this available up here:
> http://apocalyptech.com/pygtk-zlib/
Hello, two brief notes here:
1) Someone on the PyGTK list mentioned that I should really be using
StringIO instead of my own hacky attempt at one, in there, and o
CJ Kucera wrote:
> Anyway, the issue turned out to be zlib.decompress() - for larger sets
> of data, if I wasn't specifying "bufsize," the malloc()s that it was
> doing behind-the-scenes must have been clobbering memory. As soon as I
> specified bufsize, everything was
bieff...@gmail.com wrote:
> If you have worked with C/C++, you know that memory-related bugs can
> be very tricky.
> More than once - working with C code - I had crashes that disappeared
> if I just added
> a 'printf', because the memory allocation scheme changed and the
> memory corrupted was not
bieff...@gmail.com wrote:
> It looks like some of the C extension you are using is causing a
> segfault or similar in python
> interpreter (or it could be a bug in the interpreter itself, but it is
> a lot less likely).
Okay... I assume by "C extension" you'd include the PyGTK stuff, right?
(ie:
Hello list!
I'm having a strange issue, and I'm not entirely certain yet where
the actual problem is (ie, Python, PyGTK, or gtk+), but I figure I'll
start here. Bear with me, this'll probably be a long explanation...
I've been building an app which is meant to be run on both Linux and
Windows.
