Thank you eo pointer indirection for detecting this.
The issue is a mix of design choices (will discuss on the ML) and
a bug in hoversel which was probably caused because of the confusing design
choices.
The problem is that while widget_item->view is set by whoever created
the item, it's automatically deleted by elm_widget_item_del. This means
that objects that decided to delete their views, but were too sloppy to
update the widget_item->view pointer to NULL, would trigger an attempt
to deleted an already deleted object. This does not happen in 1.7
because widget_item->view was introduced in 1.8.
The automatic view deletion is problematic, as smart subobjects are
already deleted when the parent subobject (the widget) is deleted. So
clearing the views is redundant. However if the widget item is manually
deleted, the view should be deleted. This causes this mixture of cases
that are problematic at best.
Indication error:
Error:
ERR<5394>:eo lib/eo/eo_ptr_indirection.x:275 eo_obj_pointer_get()
obj_id 0x8000002900000149 is not pointing to a valid object. Maybe
it has already been freed.
This fixes T500.
static void
_hover_end(Eo *obj, void *_pd, va_list *list EINA_UNUSED)
{
+ Elm_Object_Item *it;
+ Eina_List *l;
Elm_Hoversel_Smart_Data *sd = _pd;
if (!sd->hover) return;
sd->expanded = EINA_FALSE;
+ EINA_LIST_FOREACH(sd->items, l, it)
+ {
+ VIEW(it) = NULL;
+ }
evas_object_del(sd->hover);
sd->hover = NULL;