Aaron Lindsay <aa...@os.amperecomputing.com> writes:
> Sorry, left off the very end of my timeline: > > On Nov 18 16:58, Aaron Lindsay wrote: >> I have, so far, discovered the following timeline: >> 1. My plugin receives a instruction execution callback for a load >> instruction. At this time, cpu->plugin_mem_cbs points to the same >> memory which will later be freed >> 2. During the handling of this callback, my plugin calls >qemu_plugin_reset() The final plugin reset should only execute in the safe async context (i.e. no other vCPUs running code). That flushes all current generated code. >> 3. Ostensibly something goes wrong here with the cleanup of >> cpu->plugin_mem_cbs??? This may be missed by the reset path (hence your patch) but it should be being reset every instruction we instrument. >> 4. Step 2 triggers the TBs to be flushed, which frees the memory pointed >> to by cpu->plugin_mem_cbs > > 5. A store exclusive instruction is translated and then executed, which > requires the use of a helper. When executed, this helper checks > cpu->plugin_mem_cbs, which is non-null, so it attempts to dereference > and use it, resulting in the assertion. It should be being reset for each instruction I think. > > -Aaron -- Alex Bennée
