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...@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 aurel...@aurel32.net http://www.aurel32.net