Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers
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.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: