Bug 764741 - zypper often segfaulting / aborting on exit
zypper often segfaulting / aborting on exit
Status: RESOLVED DUPLICATE of bug 761873
Classification: openSUSE
Product: openSUSE 12.2
Classification: openSUSE
Component: libzypp
Factory
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 14:53 UTC by Stefan Seyfried
Modified: 2012-05-31 12:32 UTC (History)
3 users (show)

See Also:
Found By: Third Party Developer/Partner
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
core of segfaulting "zypper in libHX-devel", first part (8.00 MB, application/octet-stream)
2012-05-31 06:50 UTC, Stefan Seyfried
Details
core of segfaulting "zypper in libHX-devel", second part (6.05 MB, application/octet-stream)
2012-05-31 06:52 UTC, Stefan Seyfried
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Seyfried 2012-05-30 14:53:38 UTC
current Factory, zypper quite often segfaults on exit or aborts due to "glibc detected double free"
Most of the time, retrying the previous command a second time works.

Running zypper under valgrind shows lots of invalid memory accesses, so something seems wrong in the code.

susi:~ # valgrind zypper up 
==7908== Memcheck, a memory error detector
==7908== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==7908== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7908== Command: zypper up
==7908== 
Loading repository data...
==7908== Invalid read of size 8
==7908==    at 0x50EBFD2: zypp::detail::RepositoryIterator::increment() (Repository.cc:319)
==7908==    by 0x511F9A3: zypp::sat::Pool::reposFind(std::string const&) const (iterator_facade.hpp:523)
==7908==    by 0x511FA58: zypp::sat::Pool::reposInsert(std::string const&) (Pool.cc:105)
==7908==    by 0x5120A2C: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, std::string const&) (Pool.cc:149)
==7908==    by 0x5120E23: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, zypp::RepoInfo const&) (Pool.cc:162)
==7908==    by 0x50E2468: zypp::RepoManager::loadFromCache(zypp::RepoInfo const&, boost::function<bool ()(zypp::ProgressData const&)> const&) (RepoManager.cc:1408)
==7908==    by 0x474119: load_repo_resolvables(Zypper&) (repos.cc:3184)
==7908==    by 0x475404: load_resolvables(Zypper&) (repos.cc:3115)
==7908==    by 0x44EF51: Zypper::doCommand() (Zypper.cc:4125)
==7908==    by 0x455E17: Zypper::safeDoCommand() (Zypper.cc:860)
==7908==    by 0x433B58: Zypper::main(int, char**) (Zypper.cc:132)
==7908==    by 0x4334BB: main (main.cc:109)
==7908==  Address 0xc41a260 is 0 bytes after a block of size 16 alloc'd
==7908==    at 0x4C292B8: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7908==    by 0x519AE34: solv_calloc (util.c:73)
==7908==    by 0x518929C: repo_create (repo.c:48)
==7908==    by 0x5136986: zypp::sat::detail::PoolImpl::_createRepo(std::string const&) (PoolImpl.cc:277)
==7908==    by 0x511FA75: zypp::sat::Pool::reposInsert(std::string const&) (Pool.cc:109)
==7908==    by 0x5120A2C: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, std::string const&) (Pool.cc:149)
==7908==    by 0x5120E23: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, zypp::RepoInfo const&) (Pool.cc:162)
==7908==    by 0x50E2468: zypp::RepoManager::loadFromCache(zypp::RepoInfo const&, boost::function<bool ()(zypp::ProgressData const&)> const&) (RepoManager.cc:1408)
==7908==    by 0x474119: load_repo_resolvables(Zypper&) (repos.cc:3184)
==7908==    by 0x475404: load_resolvables(Zypper&) (repos.cc:3115)
==7908==    by 0x44EF51: Zypper::doCommand() (Zypper.cc:4125)
==7908==    by 0x455E17: Zypper::safeDoCommand() (Zypper.cc:860)
==7908== 
Reading installed packages...
==7908== Invalid read of size 8
==7908==    at 0x50EBFD2: zypp::detail::RepositoryIterator::increment() (Repository.cc:319)
==7908==    by 0x511F9A3: zypp::sat::Pool::reposFind(std::string const&) const (iterator_facade.hpp:523)
==7908==    by 0x511FA58: zypp::sat::Pool::reposInsert(std::string const&) (Pool.cc:105)
==7908==    by 0x511FB8A: zypp::sat::Pool::systemRepo() (Pool.cc:142)
==7908==    by 0x500446D: zypp::target::TargetImpl::load() (TargetImpl.cc:988)
==7908==    by 0x46D034: load_target_resolvables(Zypper&) (repos.cc:3231)
==7908==    by 0x475467: load_resolvables(Zypper&) (repos.cc:3117)
==7908==    by 0x44EF51: Zypper::doCommand() (Zypper.cc:4125)
==7908==    by 0x455E17: Zypper::safeDoCommand() (Zypper.cc:860)
==7908==    by 0x433B58: Zypper::main(int, char**) (Zypper.cc:132)
==7908==    by 0x4334BB: main (main.cc:109)
==7908==  Address 0xce9d148 is 0 bytes after a block of size 88 alloc'd
==7908==    at 0x4C2ACCE: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7908==    by 0x519AD4D: solv_realloc (util.c:52)
==7908==    by 0x518930B: repo_create (repo.c:51)
==7908==    by 0x5136986: zypp::sat::detail::PoolImpl::_createRepo(std::string const&) (PoolImpl.cc:277)
==7908==    by 0x511FA75: zypp::sat::Pool::reposInsert(std::string const&) (Pool.cc:109)
==7908==    by 0x5120A2C: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, std::string const&) (Pool.cc:149)
==7908==    by 0x5120E23: zypp::sat::Pool::addRepoSolv(zypp::filesystem::Pathname const&, zypp::RepoInfo const&) (Pool.cc:162)
==7908==    by 0x50E2468: zypp::RepoManager::loadFromCache(zypp::RepoInfo const&, boost::function<bool ()(zypp::ProgressData const&)> const&) (RepoManager.cc:1408)
==7908==    by 0x474119: load_repo_resolvables(Zypper&) (repos.cc:3184)
==7908==    by 0x475404: load_resolvables(Zypper&) (repos.cc:3115)
==7908==    by 0x44EF51: Zypper::doCommand() (Zypper.cc:4125)
==7908==    by 0x455E17: Zypper::safeDoCommand() (Zypper.cc:860)
==7908== 

etc.pp.
Comment 1 Michael Gorse 2012-05-30 19:57:57 UTC
It looks as though the modalias list is being corrupted somehow, and both seg faults are related to it, but today I can't reproduce the bug at all, even though I was seeing it yesterday...
Comment 2 Stefan Seyfried 2012-05-31 06:50:53 UTC
Created attachment 493093 [details]
core of segfaulting "zypper in libHX-devel", first part

right now I had it reproducible segfault with:

susi:~ # zypper in libHX-devel
Loading repository data...
Reading installed packages...
Segmentation fault

it did not want to crash with valgrind or gdb, so I created a core file.

These are the files / versions I have installed:

susi:~ # rpm -qa *zypp*
zypper-debuginfo-1.7.2-2.3.x86_64
zypper-1.7.2-2.3.x86_64
libzypp-11.6.0-1.3.x86_64
libzypp-debuginfo-11.6.0-1.3.x86_64
zypper-log-1.7.2-2.3.noarch

(I could pack up the debuginfo's if necessary for debugging in case there are already newer versions on the servers...)
Comment 3 Stefan Seyfried 2012-05-31 06:52:15 UTC
Created attachment 493095 [details]
core of segfaulting "zypper in libHX-devel", second part

put together with "cat core.lzma.a* > core.lzma", then decompress with "lzma -d core.lzma"
Comment 4 Duncan Mac-Vicar 2012-05-31 12:32:09 UTC
Hi, we just submitted new packages. Please update libzypp and libsolv once those two get in:

https://build.opensuse.org/request/show/123009
https://build.opensuse.org/request/show/123019

For libsolv-tools /devel, make sure the changelog has:

 -------------------------------------------------------------------
+Wed May 30 14:46:48 CEST 2012 - mls@suse.de
+
+- fix build for older suse versions
+- fix memory corruption in unneeded calculation when there are
+  product buddies
+
+-------------------------------------------------------------------

and for libzypp:

 -------------------------------------------------------------------
+Thu May 31 10:07:37 UTC 2012 - dmacvicar@suse.com
+
+- fix an invalid read revealed by valgrind in
+  RepositoryIterator::increment()
+

You can check your installed versions by doing:

rpm -q --changelog libzypp | head
rpm -q --changelog libsolv-tools | head


If the crashes continue afterwards, please reopen.

*** This bug has been marked as a duplicate of bug 761873 ***