right list for SIGABRT python binary question ?

[dieter]

Karsten Hilbert <Karsten.Hilbert at 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.