test_job_process can fail in test 'with environment of unnamed instance'

Bug #1086474 reported by James Hunt on 2012-12-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
upstart
Undecided
Stéphane Graber

Bug Description

Attempting to build lp:upstart in a PPA results consistently in the following test failure:

Testing job_process_run()
...with simple command
...with shell command
...with small script
...with small script and trailing newlines
...with script that will fail
...with environment of unnamed instance
BAD: wrong content in file 0x225e120 (output), expected 'UPSTART_INSTANCE=
' got 'PWD=/
'
 at tests/test_job_process.c:682 (test_run).
FAIL: test_job_process

The test in question is checking that every environment variable is as expected, but here, it complains since the PWD variable was found when it expected the UPSTART_INSTANCE variable.

Related branches

James Hunt (jamesodhunt) on 2012-12-04
Changed in upstart:
assignee: nobody → James Hunt (jamesodhunt)
status: New → In Progress
James Hunt (jamesodhunt) wrote :

This test failure has so far only been seen when building lp:upstart in a PPA, using the lp:ubuntu/upstart packaging branch:

https://code.launchpad.net/~jamesodhunt/+recipe/upstart-daily

The PPA builder is an Ubuntu hardy system with a Xen kernel. Changing to a non-virtualised PPA builder did not help:

https://code.launchpad.net/~jamesodhunt/+recipe/upstart-daily-nonvirt

I have now managed to recreate a very similar issue whereby the same test as above is failing but in a different manner. To do this, I created a hardy (8.04.4) server install containing a precise schroot and ran the tests from there:

...with script that will fail
...with environment of unnamed instance
BAD: wrong value for stat (filename, &statbuf), expected 0 got -1
 at tests/test_job_process.c:675 (test_run).
/bin/bash: line 5: 6538 Aborted ${dir}$tst
FAIL: test_job_process

Debugging reveals that in job_process_spawn() after the fork():

(1) the symbol 'environ' is NULL, which is surprising.
(2) After the assignment operation below, 'environ' is *still* NULL even though 'env' is perfectly valid:

 640 /* Set the process environment from the function parameters. */
 641 environ = (char **)env;

Here's what gdb in quantal says about the environ variable:
_______________________________________________________

(gdb) info var environ
All variables matching regular expression "environ":

File environ.c:
char **__environ;
char **_environ;
char **environ;

File setenv.c:
static char **last_environ;

File environ.c:
char **__environ;
char **_environ;
char **environ;

Non-debugging symbols:
0x080bd5c0 __environ@@GLIBC_2.0
0x080bd5c0 environ@@GLIBC_2.0
(gdb)
_______________________________________________________

Whereas the equivalent in hardy shows:
_______________________________________________________
(gdb) info var environ
All variables matching regular expression "environ":

Non-debugging symbols:
0x080bd5c0 __environ@@GLIBC_2.0
0x080bd5c0 environ@@GLIBC_2.0
0xb7f34e04 __environ
0xb7f34e04 _environ
(gdb)
_______________________________________________________

James Hunt (jamesodhunt) wrote :

The fact that environ is NULL in gdb is apparently 'expected' (even though it is wrong) - gdb is looking at the wrong version of the symbol.

So, after some issues with LD_LIBRARY_PATH in my test env, it seems that it is not possible to recreate this failure on a hardy in a precise/quantal schroot.

The question also still remains as to why this problem is seen when building lp:upstart, but not when building lp:ubuntu/upstart for Ubuntu. Building lp:upstart in a virt or non-virt PPA gives the same failures.

James Hunt (jamesodhunt) on 2012-12-17
Changed in upstart:
assignee: James Hunt (jamesodhunt) → nobody
Changed in upstart:
status: In Progress → Fix Committed
James Hunt (jamesodhunt) on 2012-12-17
Changed in upstart:
assignee: nobody → Stéphane Graber (stgraber)
Changed in upstart:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers