Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
I finally achieved a successful non-SMP build of glib2.0 (2.44.1-1.1) on my PWS-433au. SMP builds are still broken: still investigating. Verified the existence of at least two tests for which the notion of "setup" and "settle" times have meaning, but since the exact failure mechanism is unknown, the best I can offer presently is advice to watch for such things. They *are* somewhat dependent on the release of libc6, as Michael and I found when an update for that package was applied a few days ago. One build issue that showed up on my system that will NOT show up on a standard buildd system concerns the use of "gdb", if present, by the "run-assert-msg-test.sh" script. First problem: "gdb" gets run on the wrapper script instead of the binary in the ".libs" subdirectory. Second problem: "gdb" cannot reference the memory location corresponding to "print (char*) __glib_assert_msg" (found in the ".gdb" file for the test). "gdb" isn't part of the base configuration, nor is it a build dependency, so the "gdb" package won't be present on a buildd system unintentionally. Suggested workaround is to ignore whether "gdb" is present and simply don't run that portion of the test. After all, if a satisfactory result is deemed to have been obtained in the absence of "gdb", why the essentially duplicate test? The irony is, the desired error message string is obtained when "gdb" runs the executable, but it's not in the output captured for subsequent processing by "grep". --Bob
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
Back in May 2014, Michael asked: "Is there a way to run an individual test? At the moment I just run 'make check' but it would be much quicker to bisect if I could run an individual test." Ditto his concern... Unlike the buildd systems, my alpha platform is slow enough that being able to make small modifications to individual tests and run them would be of significant value in getting the various FTBFS issues resolved. Yes, I said "various", as in "multiple-different-but-potentially- related." I'm getting a FTBFS on the current (Sept. 2015) glib2.0 source package for sid on alpha, and while the failures are not identical to those previously reported (one of mine occurs during the "mimeapps" testing), there are enough similarities to be a concern. My system (non-SMP) generates a segfault during one of the "mimeapps" tests, whereas the buildd system has no problem with *that* particular test, but fails elsewhere. Recently, Michael and I have renewed efforts to get glib2.0 built on alpha. Help from the package maintainers as far as figuring out how to run specific individual tests standalone would be a *huge* help to us. Thanks in advance for any assistance provided. --Bob
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
Package: glib2.0 Version: 2.40.0-5 Followup-For: Bug #746925 The glibc2.0 also fails to build from source on hppa for the same reason: ERROR: async-splice-output-stream = # random seed: R02Se318b0c8449b0f0964a60c8aa6747446 # Start of async-splice tests ok 1 /async-splice/copy-chunks PASS: async-splice-output-stream 1 /async-splice/copy-chunks Segmentation fault (core dumped) ok 2 /async-splice/copy-chunks-threaded-input PASS: async-splice-output-stream 2 /async-splice/copy-chunks-threaded-input ERROR: async-splice-output-stream - missing test plan ERROR: async-splice-output-stream - exited with status 139 (terminated by signal 11?) Full buildd log is here: http://buildd.debian-ports.org/status/fetch.php?pkg=glib2.0arch=hppaver=2.40.0-5stamp=1410540994 -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.16.2+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
It's not possible to bisect the failed glib2.0 test (async-splice-output-stream) on alpha as the commit that brings in the new test is the first one to fail. Looks like the bug was always there but never trapped by the test suite until a test was introduced. Interestingly the async-splice-output-steam test only fails when run under an SMP kernel. It always passes on a single CPU system. I note the test does a call to the pthread code; that's probably the problem --- there is definitely something occassionly racey in the Alpha pthread library that is only exposed when running under a multi-CPU system. For the time being I have put glib2.0 into the do-not-take-for-building list of the multi-cpu buildd, thus hopefully the next upload should build successfully on the other (UP) buildd. Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
On Sun, May 04, 2014 at 05:03:42PM +0200, Emilio Pozuelo Monfort wrote: I bisected with upstream source from a working version to find that commit be25603b947876f13ab7d9cee6a8c367f8f528ff (Updated Serbian translation) is the offending commit Indeed, removing this commit from Debian source version 2.40.0-3 results in glib2.0 building to completion on Alpha. Are you sure that this commit is the culprit? Bah, not any longer. I would rather guess that the test is intermittently failing (e.g. because of a race condition), and that it randomly passed after you reverted that commit while it randomly failed with that commit applied. Despite rerunning the test with and without that commit at the time and getting results consistent with the above being the problematic commit, the first time I reran it today proved my hypothesis false. It now appears that there is about a 40% to 50% chance of the test suite failing even without the Serb. transl. commit. I will have to redo the bisection. Is there a way to run an individual test? At the moment I just run 'make check' but it would be much quicker to bisect if I could run an individual test. Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
Hi, On 04/05/14 02:38, Michael Cree wrote: Source: glib2.0 Version: 2.40.0-3 Severity: important User: debian-al...@lists.debian.org Usertags: alpha Justification: Fails to build from source but built in the past. glib2.0 FTBFS on alpha due to the following test-suite error: PASS: async-splice-output-stream 1 /async-splice/copy-chunks PASS: async-splice-output-stream 2 /async-splice/copy-chunks-threaded-input ERROR: async-splice-output-stream - missing test plan ERROR: async-splice-output-stream - exited with status 133 (terminated by signal 5?) Full build log at: http://buildd.debian-ports.org/status/fetch.php?pkg=glib2.0arch=alphaver=2.40.0-3stamp=1398626766 I bisected with upstream source from a working version to find that commit be25603b947876f13ab7d9cee6a8c367f8f528ff (Updated Serbian translation) is the offending commit Indeed, removing this commit from Debian source version 2.40.0-3 results in glib2.0 building to completion on Alpha. I suppose you / the buildd aren't running with a serbian locale? Are you sure that this commit is the culprit? I would rather guess that the test is intermittently failing (e.g. because of a race condition), and that it randomly passed after you reverted that commit while it randomly failed with that commit applied. Please run the test in a loop and see if it consistently fails with that commit and if it consistently passes without it. Thanks, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746925: glib2.0 FTBFS on alpha: test-suite failure in async-splice-output-stream
Source: glib2.0 Version: 2.40.0-3 Severity: important User: debian-al...@lists.debian.org Usertags: alpha Justification: Fails to build from source but built in the past. glib2.0 FTBFS on alpha due to the following test-suite error: PASS: async-splice-output-stream 1 /async-splice/copy-chunks PASS: async-splice-output-stream 2 /async-splice/copy-chunks-threaded-input ERROR: async-splice-output-stream - missing test plan ERROR: async-splice-output-stream - exited with status 133 (terminated by signal 5?) Full build log at: http://buildd.debian-ports.org/status/fetch.php?pkg=glib2.0arch=alphaver=2.40.0-3stamp=1398626766 I bisected with upstream source from a working version to find that commit be25603b947876f13ab7d9cee6a8c367f8f528ff (Updated Serbian translation) is the offending commit Indeed, removing this commit from Debian source version 2.40.0-3 results in glib2.0 building to completion on Alpha. Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
