Bug 1173550

Summary: zypper dumps core on specific subcommands lu, lp, pch
Product: [openSUSE] openSUSE Distribution Reporter: David Fleck <dcfleck>
Component: libzyppAssignee: E-mail List <zypp-maintainers>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: meissner
Version: Leap 15.1   
Target Milestone: ---   
Hardware: x86-64   
OS: SUSE Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description David Fleck 2020-07-01 00:05:49 UTC
System:  Lenovo ThinkPad Edge E531, OpenSUSE Leap 15.1 upgraded from 42.3.
Problem: zypper dumps core when using any of the subcommands: lu, lp, pch. Error message is identical for each of the 3 cases:

# zypper -vv lu
Verbosity: 3
Initializing Target
Checking whether to refresh metadata for Non-OSS Repository
Checking whether to refresh metadata for Main Repository
Checking whether to refresh metadata for Main Update Repository
Checking whether to refresh metadata for Update Repository (Non-Oss)
Loading repository data...
Reading installed packages...
Force resolution: No
/usr/include/c++/7/bits/stl_vector.h:797: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >; std::vector<_Tp, _Alloc>::reference = std::__cxx11::basic_string<char>&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)

# zypper -V
zypper 1.14.37

# tail /var/log/zypper.log
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [libsolv++] PoolImpl.cc(logSat):123 done solving.
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [libsolv++] PoolImpl.cc(logSat):123 
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [libsolv++] PoolImpl.cc(logSat):123 solver took 580 ms
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [libsolv++] PoolImpl.cc(logSat):123 final solver statistics: 0 problems, 0 learned rules, 0 unsolvable
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [libsolv++] PoolImpl.cc(logSat):123 solver_solve took 796 ms
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [zypp::solver] SATResolver.cc(establish):222 Establish DONE
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [zypp] TargetImpl.cc(updateFileContent):786 updating '/var/lib/zypp/LastDistributionFlavor' content.
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [zypp] TargetImpl.cc(load):1177 Target loaded: 3376 resolvables
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [zypper] repos.cc(load_resolvables):1759 Done loading resolvables
2020-06-30 18:47:00 <1> moira2.sourballs.org(18053) [zypper] basecommand.cc(defaultSystemSetup):199 -------------- Calling SAT Solver to establish the PPP status -------------------
[end of file]

Not sure what other information would be helpful. I assume the problem is something in the machine's environment interacting badly with zypper, but I don't know what zypper is looking for at this point in the code that would cause this error.  Because it is machine-specific, I don't really know what would need to be done to a machine to reproduce the error (I have a second identical laptop that does not have the problem).
Comment 1 Michael Andres 2020-07-01 08:03:41 UTC
There seem to be history files with embedded NUL charactes which break the parser. Workaround, in case your file is corrupted similar to the reported ones:

  Backup: 
  cp /var/log/zypp/history /var/log/zypp/history.orig
  
  Remove embedded zeros:
  cat /var/log/zypp/history.orig | tr -d '\000' >/var/log/zypp/history

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