zdtm test build failure on s390x (s390x_regs_check.c)

Submitted by Michael Holzheu on Sept. 5, 2017, 5:47 p.m.

Details

Message ID 20170905194726.39e5edca@TP-holzheu
State New
Headers show

Commit Message

Michael Holzheu Sept. 5, 2017, 5:47 p.m.
On Tue, 5 Sep 2017 17:56:08 +0200
Adrian Reber <adrian@lisas.de> wrote:

> When running 'make zdtm' on s390x it fails on my RHEL kernel with:
> 
> make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
>  CC        s390x_regs_check.o
> s390x_regs_check.c: In function ‘util_hexdump_grp’:
> s390x_regs_check.c:214:7: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>    ptr += sprintf(ptr, "%02x", buf[i]);
>        ^

Obviously the compiler does not understand the "if (first)" construct.

I assume the following will fix the problem:
---
[CRIU][PATCH] zdtm/s390x_regs_check: Fix compiler warning

When running 'make zdtm' on s390x it fails on RHEL7 with:

 make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
  CC        s390x_regs_check.o
 s390x_regs_check.c: In function "util_hexdump_grp":
 s390x_regs_check.c:214:7: error: "ptr" may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
    ptr += sprintf(ptr, "%02x", buf[i]);

Fix this and assign ptr from the beginning to help gcc.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 test/zdtm/static/s390x_regs_check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/test/zdtm/static/s390x_regs_check.c b/test/zdtm/static/s390x_regs_check.c
index a92679a..1a7e841 100644
--- a/test/zdtm/static/s390x_regs_check.c
+++ b/test/zdtm/static/s390x_regs_check.c
@@ -198,8 +198,8 @@  struct reg_set *reg_set_vec[] = {
 void util_hexdump_grp(const char *tag, const void *data, int grp,
 		      int count, int indent)
 {
+	char str[1024], *ptr = str;
 	const char *buf = data;
-	char str[1024], *ptr;
 	int i, first = 1;
 
 	for (i = 0; i < count; i++) {

Comments

Adrian Reber Sept. 6, 2017, 3:49 p.m.
On Tue, Sep 05, 2017 at 07:47:26PM +0200, Michael Holzheu wrote:
> On Tue, 5 Sep 2017 17:56:08 +0200
> Adrian Reber <adrian@lisas.de> wrote:
> 
> > When running 'make zdtm' on s390x it fails on my RHEL kernel with:
> > 
> > make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
> >  CC        s390x_regs_check.o
> > s390x_regs_check.c: In function ‘util_hexdump_grp’:
> > s390x_regs_check.c:214:7: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >    ptr += sprintf(ptr, "%02x", buf[i]);
> >        ^
> 
> Obviously the compiler does not understand the "if (first)" construct.
> 
> I assume the following will fix the problem:
> ---
> [CRIU][PATCH] zdtm/s390x_regs_check: Fix compiler warning
> 
> When running 'make zdtm' on s390x it fails on RHEL7 with:
> 
>  make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
>   CC        s390x_regs_check.o
>  s390x_regs_check.c: In function "util_hexdump_grp":
>  s390x_regs_check.c:214:7: error: "ptr" may be used uninitialized
>  in this function [-Werror=maybe-uninitialized]
>     ptr += sprintf(ptr, "%02x", buf[i]);
> 
> Fix this and assign ptr from the beginning to help gcc.
> 
> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> ---
>  test/zdtm/static/s390x_regs_check.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/test/zdtm/static/s390x_regs_check.c b/test/zdtm/static/s390x_regs_check.c
> index a92679a..1a7e841 100644
> --- a/test/zdtm/static/s390x_regs_check.c
> +++ b/test/zdtm/static/s390x_regs_check.c
> @@ -198,8 +198,8 @@ struct reg_set *reg_set_vec[] = {
>  void util_hexdump_grp(const char *tag, const void *data, int grp,
>  		      int count, int indent)
>  {
> +	char str[1024], *ptr = str;
>  	const char *buf = data;
> -	char str[1024], *ptr;
>  	int i, first = 1;
>  
>  	for (i = 0; i < count; i++) {
> -- 
> 2.7.4

Thanks the patch works. Now it compiles without errors. But...

The test seems to hang. criu never starts in zdtm.py to do the actual
dump. In the output file I see:

11:48:08.040: 45159: ------------- START 1 PROCESS + 2 THREADS ---------------
11:48:08.080: 45159: STARTED: pid = 45160
11:48:08.149: 45159: STARTED: pid = 45162
11:48:08.149: 45159: STARTED: pid = 45161
11:48:08.149: 45159: ---------------------- SET REGISTERS --------------------
11:48:08.149: 45159: SET: pid = 45160
11:48:08.174: 45159:  REGSET:      PRFPREG -> DONE
11:48:08.174: 45159:  REGSET:     VXRS_LOW -> not supported by machine
11:48:08.174: 45159:  REGSET:    VXRS_HIGH -> not supported by machine
11:48:08.174: 45159: SET: pid = 45162

One of the three process uses 100% CPU and that is how the process tree looks like:

45166 pts/0    S+     0:00  |       \_ python2 ./zdtm.py run -f h,ns -t zdtm/static/s390x_regs_check
45176 pts/0    S+     0:00  |           \_ ./zdtm_ct zdtm.py
45179 pts/0    S+     0:00  |           |   \_ python2 zdtm.py
45182 pts/0    S+     0:00  |           |       \_ python2 zdtm.py
45199 pts/0    S+     0:00  |           |           \_ make --no-print-directory -C zdtm/static s390x_regs_check.pid
45214 pts/0    S+     0:00  |           |               \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
45215 ?        Ss     0:00  |           |                   \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
45216 ?        Rl     0:16  |           |                       \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
45219 pts/0    R+     0:00  |           \_ ps axf

		Adrian
Michael Holzheu Sept. 6, 2017, 4:33 p.m.
On Wed, 6 Sep 2017 17:49:30 +0200
Adrian Reber <adrian@lisas.de> wrote:

> On Tue, Sep 05, 2017 at 07:47:26PM +0200, Michael Holzheu wrote:
> > On Tue, 5 Sep 2017 17:56:08 +0200
> > Adrian Reber <adrian@lisas.de> wrote:
> > 
> > > When running 'make zdtm' on s390x it fails on my RHEL kernel with:
> > > 
> > > make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
> > >  CC        s390x_regs_check.o
> > > s390x_regs_check.c: In function ‘util_hexdump_grp’:
> > > s390x_regs_check.c:214:7: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > >    ptr += sprintf(ptr, "%02x", buf[i]);
> > >        ^
> > 
> > Obviously the compiler does not understand the "if (first)" construct.
> > 
> > I assume the following will fix the problem:
> > ---
> > [CRIU][PATCH] zdtm/s390x_regs_check: Fix compiler warning
> > 
> > When running 'make zdtm' on s390x it fails on RHEL7 with:
> > 
> >  make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
> >   CC        s390x_regs_check.o
> >  s390x_regs_check.c: In function "util_hexdump_grp":
> >  s390x_regs_check.c:214:7: error: "ptr" may be used uninitialized
> >  in this function [-Werror=maybe-uninitialized]
> >     ptr += sprintf(ptr, "%02x", buf[i]);
> > 
> > Fix this and assign ptr from the beginning to help gcc.
> > 
> > Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > ---
> >  test/zdtm/static/s390x_regs_check.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/test/zdtm/static/s390x_regs_check.c b/test/zdtm/static/s390x_regs_check.c
> > index a92679a..1a7e841 100644
> > --- a/test/zdtm/static/s390x_regs_check.c
> > +++ b/test/zdtm/static/s390x_regs_check.c
> > @@ -198,8 +198,8 @@ struct reg_set *reg_set_vec[] = {
> >  void util_hexdump_grp(const char *tag, const void *data, int grp,
> >  		      int count, int indent)
> >  {
> > +	char str[1024], *ptr = str;
> >  	const char *buf = data;
> > -	char str[1024], *ptr;
> >  	int i, first = 1;
> >  
> >  	for (i = 0; i < count; i++) {
> > -- 
> > 2.7.4
> 
> Thanks the patch works. Now it compiles without errors. But...
> 
> The test seems to hang. criu never starts in zdtm.py to do the actual
> dump. In the output file I see:
> 
> 11:48:08.040: 45159: ------------- START 1 PROCESS + 2 THREADS ---------------
> 11:48:08.080: 45159: STARTED: pid = 45160
> 11:48:08.149: 45159: STARTED: pid = 45162
> 11:48:08.149: 45159: STARTED: pid = 45161
> 11:48:08.149: 45159: ---------------------- SET REGISTERS --------------------
> 11:48:08.149: 45159: SET: pid = 45160
> 11:48:08.174: 45159:  REGSET:      PRFPREG -> DONE
> 11:48:08.174: 45159:  REGSET:     VXRS_LOW -> not supported by machine
> 11:48:08.174: 45159:  REGSET:    VXRS_HIGH -> not supported by machine
> 11:48:08.174: 45159: SET: pid = 45162

Looks like it started all threads and somehow hangs when attaching to
the second thread with pid=45162 in ptrace_attach().

> 
> One of the three process uses 100% CPU and that is how the process tree looks like:

After a thread is started it loops to ensure that it does not change
registers any more:

static inline void send_tid_and_loop(int fd)
{
        int tid = syscall(__NR_gettid);

        asm volatile(
                     "lgr       2,%0\n" /* Arg 1: fd */
                     "la        3,%1\n" /* Arg 2: &tid */
                     "lghi      4,4\n"  /* Arg 3: sizeof(int) */
                     "svc       4\n"    /* __NR_write SVC: */
                     /* After SVC no more registers are changed */
                     "0:        j 0b\n" /* Loop here */
                     : : "d" (fd), "Q" (tid) : "2", "3", "4");
}

> 
> 45166 pts/0    S+     0:00  |       \_ python2 ./zdtm.py run -f h,ns -t zdtm/static/s390x_regs_check
> 45176 pts/0    S+     0:00  |           \_ ./zdtm_ct zdtm.py
> 45179 pts/0    S+     0:00  |           |   \_ python2 zdtm.py
> 45182 pts/0    S+     0:00  |           |       \_ python2 zdtm.py
> 45199 pts/0    S+     0:00  |           |           \_ make --no-print-directory -C zdtm/static s390x_regs_check.pid
> 45214 pts/0    S+     0:00  |           |               \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
> 45215 ?        Ss     0:00  |           |                   \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
> 45216 ?        Rl     0:16  |           |                       \_ ./s390x_regs_check --pidfile=s390x_regs_check.pid --outfile=s390x_regs_check.out
> 45219 pts/0    R+     0:00  |           \_ ps axf

I probable will not be able to look into this the next two weeks.
Alice will be back next week. I hope she can help you then.

Michael