Attached to the mail counter.c when running with attached test.c compiled
to Linux standalone binary shows failing assert, unless the patch is
applied.
вс, 10 мая 2020 г. в 02:00, Emilio G. Cota <c...@braap.org>:
> On Mon, Apr 20, 2020 at 13:04:51 +0300, Nikolay Igotti wrote:
> > In linux-user multithreaded scenarious CPU could be inited many times
> with
> > the same id,
> > so avoid assertions on already present hashtable entry.
> >
> > Signed-off-by: Nikolay Igotti <igo...@gmail.com>
> > ---
> > plugins/core.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/plugins/core.c b/plugins/core.c
> > index 51bfc94787..889cc6441a 100644
> > --- a/plugins/core.c
> > +++ b/plugins/core.c
> > @@ -196,13 +196,10 @@ plugin_register_cb_udata(qemu_plugin_id_t id, enum
> > qemu_plugin_event ev,
> >
> > void qemu_plugin_vcpu_init_hook(CPUState *cpu)
> > {
> > - bool success;
> > -
> > qemu_rec_mutex_lock(&plugin.lock);
> > plugin_cpu_update__locked(&cpu->cpu_index, NULL, NULL);
> > - success = g_hash_table_insert(plugin.cpu_ht, &cpu->cpu_index,
> > + g_hash_table_insert(plugin.cpu_ht, &cpu->cpu_index,
> > &cpu->cpu_index);
> > - g_assert(success);
> > qemu_rec_mutex_unlock(&plugin.lock);
>
> Do you have a reproducer for this? I'd expect (1) the g_hash_table_remove
> call in qemu_plugin_vcpu_exit_hook to clear this entry upon CPU exit,
> and (2) no two live CPUs to have the same cpu_index. But maybe assumption
> (2) is wrong, or simply (1) does not get called for some exiting CPUs,
> in which case the right fix would be to make sure that it does get called
> on CPU exit.
>
> Thanks,
>
> Emilio
>
