Karsten Hilbert <karsten.hilb...@gmx.net> writes: > On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote: >> It points to a memory corruption. > While running valgrind and friends is beyond my capabilitis I > have run the problem through gdb to at least obtain a stack > trace to see what gives:
The i386/x64 architecture supports memory access breakpoints and GDB, too, has support for this. You know the address which gets corrupted. Thus, the following apporach could have a chance to succeed: Put a "memory write" breakpoint on the address which gets corrupted. this should stop the program each time this address is written; Check then the backtrace. As the address forms part of the address block prologue, it should only be accessed from Python's "malloc" (and "free") implementation. Any other access indicates bad behaviour. Should your program get stopped too often (because the memory block is reused too often), you must find a good point in your program to activate the memory access breakpoint in a delayed way. You could use the Python debugger for this: execute significant parts of your program in the Python debugger; switching to GDB, check whether the address is already corrupted - if so, restart and refine the checks above in the portion of your program which caused the corruption. If the part in your program is sufficiently small, you can activate the memory access breakpoint. This approach may also be feasible, should you use a CPU without memory access breakpoints. -- https://mail.python.org/mailman/listinfo/python-list
