Problems running kinit on HP-UX 11.00, 11i - Kerberos

This is a discussion on Problems running kinit on HP-UX 11.00, 11i - Kerberos ; I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable". Running kinit gives the following: $ kinit Assertion failed: i->did_run != 0, file ../../include/k5-platform.h, line 232 Abort(coredump) $ gdb kinit core Core was generated by `kinit'. Program terminated with signal ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Problems running kinit on HP-UX 11.00, 11i

  1. Problems running kinit on HP-UX 11.00, 11i

    I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable".
    Running kinit gives the following:
    $ kinit
    Assertion failed: i->did_run != 0, file ../../include/k5-platform.h, line 232
    Abort(coredump)

    $ gdb kinit core
    Core was generated by `kinit'.
    Program terminated with signal 6, Aborted.
    SI_UNKNOWN - signal of unknown origin
    gdb> bt
    #0 0xc01f6c50 in kill+0x10 () from /usr/lib/libc.2
    #1 0xc0193e2c in raise+0x24 () from /usr/lib/libc.2
    #2 0xc01d453c in abort_C+0x16c () from /usr/lib/libc.2
    #3 0xc01d4594 in abort+0x1c () from /usr/lib/libc.2
    #4 0xc016209c in _assert+0x178 () from /usr/lib/libc.2
    #5 0xc2022858 in k5_call_init_function+0x98 ()
    from /opt/TWWfsw/krb5141/lib/libkrb5.3
    #6 0xc20231e8 in krb5int_initialize_library+0x30 ()
    from /opt/TWWfsw/krb5141/lib/libkrb5.3
    #7 0xc20ba17c in init_common+0x44 () from /opt/TWWfsw/krb5141/lib/libkrb5.3
    #8 0xc20ba048 in krb5_init_context+0x38 ()
    from /opt/TWWfsw/krb5141/lib/libkrb5.3
    #9 0x405c in k5_begin+0x48 ()
    #10 0x5a0c in main+0x22c ()

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Problems running kinit on HP-UX 11.00, 11i

    On May 12, 2005, at 14:20, Albert Chin wrote:
    > I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable".
    > Running kinit gives the following:
    > $ kinit
    > Assertion failed: i->did_run != 0, file ../../include/k5-platform.h,
    > line 232
    > Abort(coredump)


    This indicates that the k5_once macro isn't doing its job correctly.
    One possible reason might be if the native C library provides a stub
    for pthread_once that never calls the indicated function. Could you
    check on that and let me know?

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Problems running kinit on HP-UX 11.00, 11i

    On Thu, May 12, 2005 at 04:51:22PM -0400, Ken Raeburn wrote:
    > On May 12, 2005, at 14:20, Albert Chin wrote:
    > >I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable".
    > >Running kinit gives the following:
    > > $ kinit
    > > Assertion failed: i->did_run != 0, file ../../include/k5-platform.h,
    > >line 232
    > > Abort(coredump)

    >
    > This indicates that the k5_once macro isn't doing its job correctly.
    > One possible reason might be if the native C library provides a stub
    > for pthread_once that never calls the indicated function. Could you
    > check on that and let me know?


    On HP-UX 11i:
    $ swlist -l fileset | grep -i 'libc cumulative patch'
    # PHCO_27434 1.0 libc cumulative patch

    $ nm /usr/lib/libc.sl | grep pthread_once
    ___pthread_once | 1171160|extern|code |$CODE$
    pthread_once | 1171144|extern|entry |
    pthread_once | 1171160|extern|code |$CODE$

    >From HP's patch description of PHCO_22923:

    On HP-UX if a nonthreaded application links to a
    thread-safed library the link will fail due to unresolved
    pthread symbols.To resolve these symbols, it is necessary to
    link the nonthreaded application to the threads library
    libpthread.But linking to that library makes the application
    threaded even if it creates no threads.Providing POSIX 1c
    thread "stubs" in HP-UX C language library have two direct
    effects for nonthreaded applications. a) POSIX 1c threads
    symbols are resolved if a nonthreaded application links to a
    thread-safed library b)We avoid the overhead of a real
    threads library -- especially the overhead associated with
    mutexes when the nonthreaded application uses thread stubs
    rather than real threads library procedures.

    Resolution:
    Stubs are provided for all pthread calls only in SHARED LIBC
    FLAVORS of the HP-UX C Library. These stubs do not have any
    functionality, these are dummy functions returning zero
    except pthread_getspecific() family of APIs which has full
    functionality implemented in the stubs. Full functionality
    is provided in the stub for the following pthread calls
    * pthread_key_create()
    * pthread_getspecific()
    * pthread_setspecific()
    * ptherad_key_delete()
    * pthread_exit()
    call to stub pthread_self() returns 1
    call to stub pthread_equal(arg1, arg2) will return
    (arg1 == arg2)
    Call to the stub pthread_create() and pthread_attr_init()
    returns ENOSYS.
    All other stub calls returns zero.
    There are two special interfaces provided for checking
    whether an application is linked to pthread library or not.
    a) __is_threadlib_linked()
    returns 1 for an applications linked to pthread
    library otherwise returns zero.
    b) __get_ismt()
    returns 1 for applications linked with libcma
    returns 2 for applications linked with libpthread
    otherwise returns 0

    Risks:
    ------
    An application may inadvertantly pick up the stubs when it
    intended to use the real pthreads APIs, or it may pick up
    the stubs when it needs cma APIs or stubs. These are all
    link order problems. An application that needs cma behavior
    must link to libcma (or the cma stubs library) and must do
    so in a supported link order,
    i.e. the link line should be shared only and should
    not contain "-lc" before -lcma.
    So long as this condition is met, the correct cma functions
    will be referenced. Similarly, a multithreaded application
    that needs pthread threads library behavior must link to
    libpthread and must do so in a supported link order, and
    only use shared libc and libpthread.
    eg : An applications wants to use pthread stubs then
    the link order should be
    $ cc test.c -lc -lpthread
    An applications wants to use pthread library then the
    link order should be
    $ cc test.c -lpthread -lc
    JAGab69119; SR 8606102984

    If I relink kinit with -lpthread, it works, mostly:
    # /opt/TWWfsw/krb5141/bin/kinit Administrator@AD.IL.THEWRITTENWORD.COM
    kinit(v5): Cannot resolve network address for KDC in requested realm
    while getting initial credentials

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Problems running kinit on HP-UX 11.00, 11i

    On Thu, May 12, 2005 at 04:13:50PM -0500, Albert Chin wrote:
    > If I relink kinit with -lpthread, it works, mostly:
    > # /opt/TWWfsw/krb5141/bin/kinit Administrator@AD.IL.THEWRITTENWORD.COM
    > kinit(v5): Cannot resolve network address for KDC in requested realm
    > while getting initial credentials


    Compiling/linking with -mt will also work:
    -mt Sets various -D flags to enable multi-threading and
    also sets -lpthread.

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Problems running kinit on HP-UX 11.00, 11i

    But we're attempting to find out *if* we're linked with the pthread
    library, not require it, when that's possible. For simple applications
    it wouldn't matter much, but we eventually want our library to be
    dynamically loadable from both threaded and non-threaded applications,
    and forcing the pthread library to be loaded into a non-threaded
    application would do bad things.

    When a system has weak symbols, this may be possible. But we need to
    know what symbol to test for, and that seems to vary across systems.
    It needs to be something that exists in the pthread library but not in
    the main C library. On some systems pthread_once has worked; on
    others, apparently it does not.

    Does HP-UX 11 have stubs for pthread_create? pthread_join?

    (Other means for figuring out if the thread library is loaded would be
    useful, but I don't think the pthread interface gives us much besides,
    for example, invoking pthread_create and seeing that it fails. Or
    perhaps, in fact, I should consider setting up a test that invokes
    pthread_once, and notes that it returns no error and fails to invoke
    the specified function....)

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Problems running kinit on HP-UX 11.00, 11i

    On Thu, May 12, 2005 at 06:51:52PM -0400, Ken Raeburn wrote:
    > But we're attempting to find out *if* we're linked with the pthread
    > library, not require it, when that's possible. For simple
    > applications it wouldn't matter much, but we eventually want our
    > library to be dynamically loadable from both threaded and
    > non-threaded applications, and forcing the pthread library to be
    > loaded into a non-threaded application would do bad things.
    >
    > When a system has weak symbols, this may be possible. But we need
    > to know what symbol to test for, and that seems to vary across
    > systems. It needs to be something that exists in the pthread
    > library but not in the main C library. On some systems pthread_once
    > has worked; on others, apparently it does not.
    >
    > Does HP-UX 11 have stubs for pthread_create? pthread_join?


    Yes.

    > (Other means for figuring out if the thread library is loaded would be
    > useful, but I don't think the pthread interface gives us much besides,
    > for example, invoking pthread_create and seeing that it fails. Or
    > perhaps, in fact, I should consider setting up a test that invokes
    > pthread_once, and notes that it returns no error and fails to invoke
    > the specified function....)


    I think this would be better. I ran the following test:
    $ cat a.c
    #include
    #include

    void
    init (void) {
    puts ("a");
    }

    int
    main (void) {
    pthread_once_t once_control = PTHREAD_ONCE_INIT;

    if (pthread_once (&once_control, init)) {
    puts ("fail");
    }
    }

    $ uname -a
    HP-UX hulk B.11.11 U 9000/785 2010914556 unlimited-user license
    $ cc a.c && ./a.out
    $ cc -mt a.c && ./a.out
    a

    $ uname -a
    SunOS gax 5.8 Generic_108528-27 sun4u sparc SUNW,Sun-Fire-V250
    $ cc a.c && ./a.out
    $ cc -mt a.c && ./a.out
    a

    $ uname -a
    OSF1 gen.il.thewrittenword.com V5.1 732 alpha
    $ cc a.c && ./a.out
    ld:
    Unresolved:
    __pthread_once
    $ cc -pthread pth.c && ./a.out
    a

    $ uname -a
    AIX luna 2 5 0043880C4C00
    $ xlc a.c && ./a.out
    ld: 0711-317 ERROR: Undefined symbol: .pthread_once
    ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
    $ xlc_r pth.c && ./a.out
    a
    $ xlc pth.c -lpthread && ./a.out
    a

    $ uname -a
    IRIX64 puar 6.5 01080747 IP30
    $ cc pth.c && ./a.out
    ld32: ERROR 33 : Unresolved text symbol "pthread_once" -- 1st
    referenced by pth.o.
    Use linker option -v to see when and which objects, archives
    and dsos are loaded.
    $ cc pth.c -lpthread && ./a.out
    a

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: Problems running kinit on HP-UX 11.00, 11i

    It seems completely broken for an OS to provide pthread_once that
    isn't funcitional. I'd recommend opening a bug with HP pointing out
    that even the non-threaded version of pthread_once does need to make
    sure the code is called exactly once.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Problems running kinit on HP-UX 11.00, 11i

    On Fri, May 13, 2005 at 10:36:59AM -0400, Sam Hartman wrote:
    > It seems completely broken for an OS to provide pthread_once that
    > isn't funcitional. I'd recommend opening a bug with HP pointing out
    > that even the non-threaded version of pthread_once does need to make
    > sure the code is called exactly once.


    Per my post with the description of patch PHCO_22923, it isn't broken.
    This is how HP designed the stub functions.

    http://mailman.mit.edu/pipermail/ker...ay/007715.html

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: Problems running kinit on HP-UX 11.00, 11i

    >>>>> "Albert" == Albert Chin writes:

    Albert> On Fri, May 13, 2005 at 10:36:59AM -0400, Sam Hartman
    Albert> wrote:
    >> It seems completely broken for an OS to provide pthread_once
    >> that isn't funcitional. I'd recommend opening a bug with HP
    >> pointing out that even the non-threaded version of pthread_once
    >> does need to make sure the code is called exactly once.


    Albert> Per my post with the description of patch PHCO_22923, it
    Albert> isn't broken. This is how HP designed the stub functions.

    A design can be broken.

    I don't believe the implementation of pthread_once in the HP libc
    meets the API specification in POSIX. That counts as broken in my
    book.

    --Sam

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: Problems running kinit on HP-UX 11.00, 11i

    On May 13, 2005, at 17:55, Sam Hartman wrote:
    > Albert> Per my post with the description of patch PHCO_22923, it
    > Albert> isn't broken. This is how HP designed the stub functions.
    >
    > A design can be broken.
    >
    > I don't believe the implementation of pthread_once in the HP libc
    > meets the API specification in POSIX. That counts as broken in my
    > book.


    One could probably argue that there is a POSIX-compliant configuration,
    and additional vendor-specific configurations, and "cc" without
    "-lpthread" (or whatever) is one of the latter. Still, it's pretty
    lame; but on the other hand, HP-UX isn't the only system that does this
    -- Solaris is similarly broken.

    (At least as of POSIX.1-1996, you can't just say, "you left out the -mt
    option therefore we can do anything we want with pthread_* and still be
    compliant". Without some magic compilation option, the implementation
    can choose not to define _POSIX_THREADS, but that doesn't let them
    screw up the function implementations. Having _POSIX_THREADS defined
    mean the pthread functions are available and do the right thing.
    Having it *not* defined means *either* they're available and do the
    right thing, or they're not available. Or, you're not complying with
    the POSIX spec.)

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  11. Re: Problems running kinit on HP-UX 11.00, 11i

    Albert, I have been out of the office. I have no experience with HP-UX.

    Milton

    At 12:20 PM 5/12/2005, you wrote:
    >I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable".
    >Running kinit gives the following:
    > $ kinit
    > Assertion failed: i->did_run != 0, file ../../include/k5-platform.h,
    > line 232
    > Abort(coredump)
    >
    > $ gdb kinit core
    > Core was generated by `kinit'.
    > Program terminated with signal 6, Aborted.
    > SI_UNKNOWN - signal of unknown origin
    > gdb> bt
    > #0 0xc01f6c50 in kill+0x10 () from /usr/lib/libc.2
    > #1 0xc0193e2c in raise+0x24 () from /usr/lib/libc.2
    > #2 0xc01d453c in abort_C+0x16c () from /usr/lib/libc.2
    > #3 0xc01d4594 in abort+0x1c () from /usr/lib/libc.2
    > #4 0xc016209c in _assert+0x178 () from /usr/lib/libc.2
    > #5 0xc2022858 in k5_call_init_function+0x98 ()
    > from /opt/TWWfsw/krb5141/lib/libkrb5.3
    > #6 0xc20231e8 in krb5int_initialize_library+0x30 ()
    > from /opt/TWWfsw/krb5141/lib/libkrb5.3
    > #7 0xc20ba17c in init_common+0x44 () from
    > /opt/TWWfsw/krb5141/lib/libkrb5.3
    > #8 0xc20ba048 in krb5_init_context+0x38 ()
    > from /opt/TWWfsw/krb5141/lib/libkrb5.3
    > #9 0x405c in k5_begin+0x48 ()
    > #10 0x5a0c in main+0x22c ()
    >
    >--
    >albert chin (china@thewrittenword.com)
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  12. Re: Problems running kinit on HP-UX 11.00, 11i

    On 1116021302 seconds since the Beginning of the UNIX epoch
    Sam Hartman wrote:
    >


    >A design can be broken.
    >
    >I don't believe the implementation of pthread_once in the HP libc
    >meets the API specification in POSIX. That counts as broken in my
    >book.


    Looks like SunOS 5.7 provides a pthread_once() that returns true
    without calling anything if -lpthread is not specified. We probably
    need a more generic solution...

    --
    Roland Dowdeswell http://www.Imrryr.ORG/~elric/
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  13. Re: Problems running kinit on HP-UX 11.00, 11i

    Albert, could you please try out the attached patch, and see if it
    fixes the kinit initialization problem?

    Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  14. Re: Problems running kinit on HP-UX 11.00, 11i

    On Thu, May 12, 2005 at 09:17:30PM -0500, Albert Chin wrote:
    > On Thu, May 12, 2005 at 06:51:52PM -0400, Ken Raeburn wrote:
    > > (Other means for figuring out if the thread library is loaded would be
    > > useful, but I don't think the pthread interface gives us much besides,
    > > for example, invoking pthread_create and seeing that it fails. Or
    > > perhaps, in fact, I should consider setting up a test that invokes
    > > pthread_once, and notes that it returns no error and fails to invoke
    > > the specified function....)

    >
    > I think this would be better. I ran the following test:
    > $ cat a.c
    > #include
    > #include
    >
    > void
    > init (void) {
    > puts ("a");
    > }
    >
    > int
    > main (void) {
    > pthread_once_t once_control = PTHREAD_ONCE_INIT;
    >
    > if (pthread_once (&once_control, init)) {
    > puts ("fail");
    > }
    > }
    >
    > $ uname -a
    > HP-UX hulk B.11.11 U 9000/785 2010914556 unlimited-user license
    > $ cc a.c && ./a.out
    > $ cc -mt a.c && ./a.out
    > a


    BTW, this is fixed with PHCO_29495.

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread