https://bugzilla.novell.com/show_bug.cgi?id=722538 https://bugzilla.novell.com/show_bug.cgi?id=722538#c7 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|YaST2 |GNOME AssignedTo|zypp-maintainers@forge.prov |bnc-team-gnome@forge.provo. |o.novell.com |novell.com QAContact|jsrain@suse.com |qa@suse.de --- Comment #7 from Michael Andres <ma@suse.com> 2011-10-25 17:28:17 CEST --- A bit clueless. And I'm not able to reproduce it. Both SEGV happen in code that is heavily used: setting a solvables status and accessing a poolitems resolvable. The same code (libzypp-9.11.0) is running on SLE11SP2, with zypper, PkgKit and seems to work with all frontends except for gtk. - in _ZNK4zypp8PoolItem10resolvableEv ResObject::constPtr PoolItem::resolvable() const { return _pimpl->resolvable(); } - in _ZN4zypp2ui10Selectable9setStatusENS0_6StatusENS_9ResStatus15... bool Selectable::setStatus( Status state_r, ResStatus::TransactByValue causer_r ) { return _pimpl->setStatus( state_r, causer_r ); } It's not that easy to create a SEGV here as the classes assert that _pimpl is always valid. So probably _pimpl refers to an invalid implementation class, which is for PoolItem hard to achieve. OTOH if I grep for ZyppSelectablePtr in the gtk code I find typedef zypp::ui::Selectable* zyppSelectablePtr; and it looks like gkt stores those pointers as callback data (install_cb, undo_cb, remove_cb) and later restores them ZyppSelectablePtr zsel = (ZyppSelectablePtr) _data; I'm not sure whether it's asserted the Selectable object still exists when the pointer is restored. And if so, it's asserted the Selectable is still valid, i.e. the pool content did not change. Maybe the gkt maintaner can check their code. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.