Bug 381917

Summary:	destructors: zypp::ZYpp::finishTarget after zypp::sat::detail::~PoolImpl
Product:	[openSUSE] openSUSE 11.0	Reporter:	Martin Vidner <mvidner>
Component:	libzypp	Assignee:	Martin Vidner <mvidner>
Status:	RESOLVED WONTFIX	QA Contact:	Duncan Mac-Vicar <dmacvicar>
Severity:	Normal
Priority:	P3 - Medium	CC:	lslezak, ma
Version:	Beta 1
Target Milestone:	---
Hardware:	Other
OS:	Other
See Also:	https://fate.suse.com/302119
Whiteboard:
Found By:	Development	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	lazy-zypp-fate302119.patch lazy-zypp-backtrace pkgsize.ycp - test script

Description Martin Vidner 2008-04-21 13:24:41 UTC

I implemented lazy loading of libzypp from yast2-pkg-bindings (fate#302119), but that makes yast crash in Pkg destructors, because they are now called after pool_free.

The problematic call in Pkg was added because of bug 228176.

Backtrace and a patch with the feature follow.

Comment 1 Martin Vidner 2008-04-21 13:25:35 UTC

Created attachment 209299 [details]
lazy-zypp-fate302119.patch

Comment 2 Martin Vidner 2008-04-21 13:26:58 UTC

Created attachment 209300 [details]
lazy-zypp-backtrace

Comment 3 Martin Vidner 2008-04-21 13:28:03 UTC

Created attachment 209301 [details]
pkgsize.ycp - test script

Comment 4 Michael Andres 2008-06-12 14:29:45 UTC

Well, you can not access zypp after the lib was unloaded.

But as we do not have Script reslovables any more, pkg-bindings could omit the target finish call without raising bug #228176 again. Those temp files are no longer created. 

Hopefully the stored zypp_pointer does not cause similar problems, as it also refers to data within zypp.

Comment 5 Ladislav Slezák 2008-06-13 08:38:05 UTC

I'll remove the targetFinish() call, but I'm not sure if I can release the zypp pointer (zypp_pointer = NULL). Michael?

Comment 6 Michael Andres 2008-06-13 09:56:13 UTC

If libzypp was unloaded it is likely that this zypp_pointer in pkg-bindings is the last reference to the global ZYpp object. 

Thus ~PkgFunctions will invoke ~ZYpp. This will invoke a bunch of other destructors, and it is hard to tell whether this will work, as all the static zypp objects seem to be already deleted at that time.

The save flow would be to make shure ~PkgFunctions is performed before libzypp is unloaded. Or at least to set the zypp_pointer to NULL before libzypp is unloaded.
Everything else is fragile.


Note that there is no need to explicitly set (zypp_pointer = NULL) in PkgFunctions. This will happen automatically in as zypp_pointer will go out of scope. So you can't prevent ~ZYpp from being called.

Comment 7 Ladislav Slezák 2008-06-13 12:10:40 UTC

I removed the code from the destructor (in SVN trunk).

Martin, what about the patches? Can they be committed? Are they ready?

Comment 8 Martin Vidner 2008-07-31 08:39:11 UTC

The problem is still there, for the reasons in comment 6. Even if we do not call targetFinish, we still call the zypp destructor, and it crashes all the same.

A clean fix is to explicitly destroy PkgFunctions (and thus zypp) before any of the static objects are destroyed. There are scores of static objects in YaST, so I find it difficult to do a clean fix. But I hope to untangle it soon.

Comment 9 Martin Vidner 2008-10-20 12:20:57 UTC

It is harder than I thought, so it will not be in this release. FATE 302119 has been postponed accordingly.

Comment 10 Martin Vidner 2010-11-02 14:49:16 UTC

This bug has been open for long but I haven't found the to fix it,
so now I close it. Sorry.

If you still care about it, please reopen it.