CUPS 1.4.7 IPP Compliance Test failure

Jerry Fowler jfowler at cerner.com
Mon Aug 27 11:44:17 PDT 2012


I did have an older version of gcc on one of the build machines, so I removed it and ran a gmake distclean, before re-running configure, gmake, and gmake check with the same result.

An ldd of the ipptest binary yields the following result:

$ ldd test/ipptest
test/ipptest needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libpthreads.a(shr_xpg5.o)
         /opt/freeware/lib/libssl.a(libssl.so.0.9.8)
         /opt/freeware/lib/libcrypto.a(libcrypto.so.0.9.8)
         /opt/freeware/lib/libz.a(libz.so.1)
         /unix
         /usr/lib/libcrypt.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libpthreads.a(shr_xpg5_64.o)
         /usr/lib/libcrypt.a(shr_64.o)
$

So I think the standard AIX C library is being used.

Any suggestions?

> Michael,
>
> That's what has me stumped also, would you recommend that I check return codes on those calls to see if I am getting a bad status back?
>
> I'll double check but I don't think gcc is installed on either of my build machines.  If I find that it is, one of my machines is isolated and I should be able to remove gcc over there and try again.  I'll post the results of the investigation.
>
> > Jerry,
> >
> > The output doesn't make a whole lot of sense to me since line 4 is a comment ("Verify that the server ...") - almost like getc or ungetc are failing or you have mixed system/GCC headers?
> >
> >
> > On Aug 17, 2012, at 2:31 PM, Jerry Fowler <jfowler at cerner.com> wrote:
> > > Currently architecture where this is failing is POWER 5.  I have two machines where I am getting the same result.  I have narrowed it down a bit by adding printf statements at certain places in ipptest.c.
> > >
> > > When I run ipptest.c on the HP-UX platform with these changes I get the following behavior:
> > >
> > > Running IPP compliance tests...
> > > Performing 4.1-requests.test...
> > > "4.1-requests.test":
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > WS delim txt, ungetting ch = {
> > > WS space or comment, ch =
> > >
> > > Results from first get_token call - token = {, linenum = 10
> > >
> > > When I run the same mods on AIX I get the following:
> > >
> > > Running IPP compliance tests...
> > > Performing 4.1-requests.test...
> > > "4.1-requests.test":
> > > Comment, got new line
> > > Comment, got new line
> > > Comment, got new line
> > > WS delim txt, ungetting ch = a
> > > WS space or comment, ch =
> > >
> > > Results from first get_token call - token = attributes-natural-language, linenum = 4
> > > Unexpected token attributes-natural-language seen on line 4 - aborting test!
> > >
> > > Here is an excerpt from the modified version of ipptest.c (get_token function):
> > >
> > >    if (ch == EOF)
> > >    {
> > >      printf("EOF reached \n");
> > >      return (NULL);
> > >    }
> > >    else if (ch == '\'' || ch == '\"')
> > >    {
> > >     /*
> > >      * Quoted text...
> > >      */
> > >
> > >      quote  = ch;
> > >      bufptr = buf;
> > >      bufend = buf + buflen - 1;
> > >
> > >      while ((ch = getc(fp)) != EOF)
> > >        if (ch == quote)
> > >          break;
> > >        else if (bufptr < bufend)
> > >          *bufptr++ = ch;
> > >
> > >      *bufptr = '\0';
> > >      return (buf);
> > >    }
> > >    else if (ch == '#')
> > >    {
> > >     /*
> > >      * Comment...
> > >      */
> > >
> > >      while ((ch = getc(fp)) != EOF)
> > >        if (ch == '\n')
> > >        {
> > >          printf("Comment, got new line \n");
> > >          break;
> > >        }
> > >
> > >      (*linenum) ++;
> > >    }
> > >    else
> > >    {
> > >     /*
> > >     /*
> > >      * Whitespace delimited text...
> > >      */
> > >
> > >      printf("WS delim txt, ungetting ch = %c \n", ch);
> > >      ungetc(ch, fp);
> > >
> > >      bufptr = buf;
> > >      bufend = buf + buflen - 1;
> > >
> > >      while ((ch = getc(fp)) != EOF)
> > >        if (isspace(ch) || ch == '#')
> > >        {
> > >          printf("WS space or comment, ch = %c \n", ch);
> > >          break;
> > >        }
> > >        else if (bufptr < bufend)
> > >          *bufptr++ = ch;
> > >
> > >      if (ch == '#')
> > >        ungetc(ch, fp);
> > >
> > >      *bufptr = '\0';
> > >      return (buf);
> > >    }
> > >  }
> > > }
> > >
> > >
> > >> What architecture are you running on? Power or ???
> > >>
> > >>
> > >> On Aug 9, 2012, at 12:14 PM, Jerry Fowler <jfowler at cerner.com> wrote:
> > >>
> > >>>> It also appears that there are multiple places in the ipptest.c code where the message "Unexpected token" can be generated.
> > >>>
> > >>> Correction: it appears that the get_token function in ipptest.c is not recognizing the entire comment statement.
> > >>>
> > >>> The first 10 lines of 4.1-requests.test are as follows (with line numbers):
> > >>>
> > >>>    1  #
> > >>>    2  # "$Id: 4.1-requests.test 8235 2009-01-13 00:55:16Z mike $"
> > >>>    3  #
> > >>>    4  #   Verify that the server requires the following attributes:
> > >>>    5  #
> > >>>    6  #       attributes-charset
> > >>>    7  #       attributes-natural-language
> > >>>    8  #       printer-uri/job-uri
> > >>>    9  #
> > >>>   10  {
> > >>>
> > >>> Even though the message from the test indicates:
> > >>>
> > >>> "4.1-requests.test":
> > >>> Unexpected token attributes-natural-language seen on line 4 - aborting test!
> > >>>
> > >>> I suspect that there is some bug in this function for the AIX platform at least that is causing it not to recognize line 7 as a comment and storing the "attributes-natural-language" at the first part of token buffer and causing the get_token to throw it out as the first character of token must be a left brace.
> > >>>
> > >>> Does that make sense?
> > >>> _______________________________________________
> > >>> cups-bugs mailing list
> > >>> cups-bugs at easysw.com
> > >>> http://lists.easysw.com/mailman/listinfo/cups-bugs
> > >>
> > >> _________________________________________________________
> > >> Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >>
> > >
> > > _______________________________________________
> > > cups-bugs mailing list
> > > cups-bugs at easysw.com
> > > http://lists.easysw.com/mailman/listinfo/cups-bugs
> >
> > __________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
>





More information about the cups-devel mailing list