On Nov 21 22:02, Alex Bennée wrote: > > 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.
FYI - I suspect my above presentation of the problem suffered from the "searching where the streetlamp is instead of where you lost something" problem. In other words, I did/do observe the error at reset, but I now believe that is merely where it is easiest to observe. The cpu->plugin_mem_cbs doesn't appear to be reset at the end of instructions and manifests at reset because that's when the underlying memory is freed. -Aaron
