[François Revol] > Now, I don't see why malloc itself would give such a result, it's > pyMalloc which places those marks, so the thing malloc does wouldn't > place them 4 bytes of each other for no reason, or repport 0 bytes > where 4 are allocated. I think you're fooling yourself if you believe 4 *were* allocated. The memory dump shows nothing but gibberish, with 4 blocks of fbfbfbfb not a one of which makes sense in context (the numbers before and after them make no sense as "# of bytes allocated" or as "serial number" values, so these forbidden-byte blocks don't make sense as either end of an active pymalloc block). You should at least try to get a C traceback at this point, on the chance that the routine passing the pointer is a clue. We don't even know here yet whether the complaint came from a free() or realloc() call. This isn't going to be easy.
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