[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers



On 2017-08-16 11:54, Aurelien Jarno wrote:
> On 2017-08-16 02:41, Andreas Beckmann wrote:
> > [ adding apt@, therefore quoting fully ]
> > 
> > On 2017-08-15 22:56, Aurelien Jarno wrote:
> > > control: tag - 1 + help
> > > control: tag - 1 + moreinfo
> > > 
> > > On 2017-08-15 09:58, Andreas Beckmann wrote:
> > >> Package: libc-bin
> > >> Version: 2.24-14
> > >> Severity: serious
> > >> User: debian-qa@lists.debian.org
> > >> Usertags: piuparts
> > >>
> > >> Hi,
> > >>
> > >> during several tests with piuparts in sid I noticed spurious and
> > >> unreproducible errors while processing libc-bin triggers.
> > >> Often apt-get just exits with an error code (but no error message
> > >> at all) after processing the triggers.
> > >> A few times I also get an error message about an uncaught exception.
> > >> These failures usually go away after rerunning the test.
> > >>
> > >> >From the attached log (scroll to the bottom...):
> > >>
> > >>   Processing triggers for libc-bin (2.24-14) ...
> > >>   terminate called after throwing an instance of 'std::logic_error'
> > >>     what():  basic_string::_M_construct null not valid
> > > 
> > > What make you think it's an issue in libc-bin? The trigger processing
> > > code just does:
> > > 
> > > if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
> > >   ldconfig || ldconfig --verbose
> > >   exit 0
> > > fi
> > > 
> > > And there is no C++ code in ldconfig. Moreover even if ldconfig fails
> > > the error is ignored and the install should not stop.
> > 
> > OK, that probably leaves dpkg (no C++ either) and apt-get as the call
> > chain to the trigger processing ... adding apt@ to the loop.
> > #871275 could be a candidate, i.e. a g++7 rebuild might fix it.
> > 
> > I reran the test where I attached the logfile yesterday repeatedly for
> > 100 times with no failure. But I could probably dig out a dozen of
> > similar failures from other piuparts tests. (These failures will be
> > retried frequently, so will eventually succeed.)
> > 
> > If there is some way to get more debug output for this problem, I could
> > enable that globally in my piuparts instance.
> 
> I guess you can try to get a core dump. Just make sure that you run
> "ulimit -c unlimited" before running the command. The core dump will
> tell you which binary actually has the issue and should provide more
> info about the issue.

Any news about this? This bug now blocks the migration of glibc to
testing.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: