On Wed, Nov 01, 2017 at 04:28:02PM +0000, Grant Edwards wrote: > >>I understand. Thank you for the explanation. This may seem > >>like a dumb question: the actual address that gets corrupted > >>varies from run to run (it may be the same "place" in the > > > > Since the process virtual memory space should be the same on each run > > Not with modern OS kernels: > > https://en.wikipedia.org/wiki/Address_space_layout_randomization
I feared as much. However, I discovered that during subsequent runs the address seems stable due to shared libraries being preloaded: On the first run the affected code is loaded at some randomized address and the corruption is hit at a certain address giving me the value to watch on during subsequent runs, as long as the affected code is not evicted from being preloaded the address is stable. I have posted backtraces taken from the address being watched. Does that help any at all ? Thanks, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
