bzr tests fail on OpenBSD 4.4/amd64

Bug #314247 reported by Martin Pool
6
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

From: Toni Mueller <email address hidden>

I tried to run the self-test suite for bzr-1.10 on OpenBSD 4.4/amd64,
but encountered a number of problems that you might be able to help me
with.

1. A large number (>> 20 in any case) of self-tests failed. It is very
important to me that these bugs be fixed. I don't know how to do it,
but want to help with it (see below).

2. I had to terminate the test run after a few hundred due to / running
full.

3. It seems to be impossible to run the test suite in the background,
with no terminal. Trying to do this:

$ nohup python2.5 ./bzr selftest --strict 2>&1 &

simply stalled my test run (it displays "Stopped" on the xterm on which
I invoked the command).

I'd like to send in a more detailed report, using 'script' to record
the output, but need to find ways to not clutter /tmp first.

proved to be impossible because the test run simply stalled. I may be
missing something, however.

Please help me run the test suite, and I'll ship you the results.

I've re-tried, and got the results that you find attached. I didn't
check whether all tests were actually performed, but simply ship
everything that the tests yieled, to you. The test run (probably) ended
when Python (2.5.2p4) segfaulted. I have the core lying around, so if
you want me to do some surgery on it, just ask for it (I don't really
know what to do). I created the "...cpio.." archive using "pax -x
sv4cpio". Rolling a tarball was impossible because of the 100 char
pathname limit in the tar archive format.

Revision history for this message
Martin Pool (mbp) wrote :
Revision history for this message
Martin Pool (mbp) wrote :

contents of tmp after test failure

Revision history for this message
Martin Pool (mbp) wrote :

.bzr.log from Tobi

Revision history for this message
Martin Pool (mbp) wrote : Re: bzr 1.10 selftests
Download full text (19.9 KiB)

On 2 Jan 2009, Toni Mueller <email address hidden> wrote:
>
> Hi Martin,
>
> On Mon, 29.12.2008 at 19:24:02 +0100, Toni Mueller <email address hidden> wrote:
> > I tried to run the self-test suite for bzr-1.10 on OpenBSD 4.4/amd64,
>
> I've re-tried, and got the results that you find attached. I didn't
> check whether all tests were actually performed, but simply ship
> everything that the tests yieled, to you. The test run (probably) ended
> when Python (2.5.2p4) segfaulted. I have the core lying around, so if
> you want me to do some surgery on it, just ask for it (I don't really
> know what to do). I created the "...cpio.." archive using "pax -x
> sv4cpio". Rolling a tarball was impossible because of the 100 char
> pathname limit in the tar archive format.

Hi,

Thanks for testing this. I opened
<https://bugs.edge.launchpad.net/bzr/+bug/314247> to make the results
available to other people.

The problems here seem to be:

Firstly, if bzr selftest doesn't run correctly without a terminal or in
nohup mode, that seems to be a bug in itself. Run under Linux with
nohup it does not write any output to the log file while it's running, I
guess because it's relying on a progress bar and that will be off if
there's no terminal, but I do get a list of failed, xfail etc tests at
the end of the run.

On Ubuntu Intrepid all the tests pass in a nohup environment pass except
for some problems in bzr-gtk.

bzr is supposed to delete temporary directories as it finishes each
test, so it shouldn't be using a large amount of disk space to run. It
is possible that particular tests will need several megabytes. As I'm
running the tests I see all of /tmp is about 12MB. If you can isolate
what is using too much space we may find a bug. Otherwise you can run
them with TMPDIR=~/tmp to put it on another filesystem.

So the substantial bugs in here are:

> blackbox.test_breakin.TestBreakin.test_breakin FAIL 619ms
> pattern "entering debugger" not found in
> """\
> No handlers could be found for logger "bzr"
> """

The logger message might be a problem with not having a console.
breakin.py seems to unconditionally, write to stderr so should not be
affected by that. It would be useful if you could try pressing C-\
while bzr is running normally, to see if there's a difference in sigquit
handling on openbsd.

> blackbox.test_check.ChrootedCheckTests.test_check_missing_branch
> ERROR 48ms
>
> (26, 'Failed to open/read local data from file/application')

> ^^^^[log from bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch]
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/sw/local/bzr-1.10/bzrlib/tests/blackbox/test_check.py", line 104, in test_check_missing_branch
> 'check --branch %s' % self.get_readonly_url(''))
> File "/home/sw/local/bzr-1.10/bzrlib/tests/__init__.py", line 1486, in run_bzr
> working_dir=working_dir,
> File "/home/sw/local/bzr-1.10/bzrlib/tests/__init__.py", line 1400, in _run_bzr_autosplit
> encoding=encoding, stdin=stdin, w...

Revision history for this message
ToniMueller (support-oeko) wrote :

Sorry for the confusion. This error:

> blackbox.test_breakin.TestBreakin.test_breakin FAIL 619ms
> pattern "entering debugger" not found in
> """\
> No handlers could be found for logger "bzr"
> """

and, in general, all error logs I sent you, were conducted in a second run where I called 'script' before, and just locked the terminal while the tests were running. IOW, a terminal should have been available at all times.

The problem with filling up /tmp I could not reproduce, but I ran the first test, where it happened, as user 'root', and both the ~/.bzr.log (how can I switch this off, please?) plus /tmp ate some 345 MB on my 400MB root partition (currently, there are only some 52 MB out of 400MB used). Also, tests showed a different failure pattern in that case, but I'm hesitant to do it again on that machine.

As should be obvious from the attached files, bzr fails to remove the temporary files and directories for tests that failed.

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 314247] Re: bzr tests fail on OpenBSD 4.4/amd64

On 6 Jan 2009, ToniMueller <email address hidden> wrote:
> The problem with filling up /tmp I could not reproduce, but I ran the
> first test, where it happened, as user 'root', and both the ~/.bzr.log
> (how can I switch this off, please?) plus /tmp ate some 345 MB on my
> 400MB root partition (currently, there are only some 52 MB out of 400MB
> used).

 ln -s /dev/null ~/.bzr.log

should work

If that machine has more than 400MB disk in total, I suggest you set
TMPDIR to run it on a different partition.

--
Martin <http://launchpad.net/~mbp>

Revision history for this message
ToniMueller (support-oeko) wrote :

If you make any progress and can tell me what to test (eg. new code), I'd be happy to do so, and report back.

Revision history for this message
Martin Pool (mbp) wrote :

This bug is languishing in part because it's too large and not a single problem. So if we can split it apart to individual classes of failure it should be easier.

The problem with eintr should now be fixed in 1.13.1 by Andrew - we retry on eintr.

The problem with options to diff is bug 314254.

Revision history for this message
Martin Pool (mbp) wrote :

Please run the 1.13.1 tests, in a plain terminal, and let's see what happens.

Changed in bzr:
importance: Undecided → Low
Martin Pool (mbp)
Changed in bzr:
importance: Low → Medium
status: New → Confirmed
Revision history for this message
Robert Collins (lifeless) wrote :

Are there any remaining components to this bug?

Revision history for this message
Martin Pool (mbp) wrote :

2009/9/25 Robert Collins <email address hidden>:
> Are there any remaining components to this bug?

There may well still be failures there but I don't know if retaining
this large bug will help fix them.

--
Martin <http://launchpad.net/~mbp/>

Vincent Ladeuil (vila)
tags: added: selftest
removed: test
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.