Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#37 top-3.7 segfaults on hpux/ia64

open
None
5
2008-07-18
2008-07-17
Peter O'Gorman
No

top-3.7 segfaults on startup on ia64-hp-hpux11.23.

utils.c:string_list() does not check if the passed in value is NULL.
Access to /dev/kmem did not return any useful results, we have to rely on pstat.
We must define _PSTAT64.

Because top works perfectly fine on hppa-hp-hpux11.00 and 11.11, we added a new file in machine and chose that via the configure option. Attached is the diff between m_hpux10.c and our "new" m_hpux11_64.c.

Discussion

  • Peter O'Gorman
    Peter O'Gorman
    2008-07-17

    Patch

     
    Attachments
    • assigned_to: nobody --> wnl
     
  • Logged In: YES
    user_id=687210
    Originator: NO

    It would be good to have configure automatically use this module on the appropriate systems. It is easy to detect HPUX 11, but can you offer guidance (or better yet, a patch) on how to modify configure.ac to automatically detect when the HPUX 11 system is 64-bit?

     
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-20

    Patch for configure.ac and screen.c

     
    Attachments
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-20

    Logged In: YES
    user_id=1889927
    Originator: YES

    Ok, an untested patch is attached.

    Also what I first thought to be a configuration problem turns out to be an issue with ia64-hpux tgetent, it returns 0 for success, not 1.

    Patch attached.
    File Added: ia64.diff

     
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-20

    Logged In: YES
    user_id=1889927
    Originator: YES

    We have now tested the patch.

     
  • Logged In: YES
    user_id=687210
    Originator: NO

    Turns out my freebsd system returns -1 for the string "nowaythisisavalidtermname" and most other invalid TERMs. So I had to adjust the patch a bit. Ideally configure should test a known terminal name to see what is returned on success, but then it would have to assume a location for termcap in order to get a known valid name. So we will keep things as is and hope it doesn't break other systems.

     
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-21

    Logged In: YES
    user_id=1889927
    Originator: YES

    Ugh. I stupidly only tested on two hp systems.
    Originally I had, in screen.c a '#if defined __hpux && defined __ia64' to special case the 0 is success code, but thought a configure time test would be best for sending upstream to you, maybe I was wrong and it is best to special case the one system like that.

    Solaris and IRIX tgetent man page says 'Routines that return an integer return ERR upon failure and an integer value other than ERR upon successful completion.', so success can be anything but -1. AIX 'Upon successful completion, subroutines that return an integer return OK. Otherwise, they return ERR.'

    The linux man page is the one that I was comparing hpux to and that one says 'It returns 1 on success, 0 if there is no such entry, and -1 if the terminfo database could not be found.'

    The thing is, of course, that hppa-hpux configure finds tgetent in libtermcap, but ia64-hpux11.23 does not have a libtermcap so it finds tgetent in libcurses, and they behave differently.

    This means, of course, that the configure test that I added is completely broken. I will look at a making a new test (and test it properly before adding it here). Sorry.

     
  • Logged In: YES
    user_id=687210
    Originator: NO

    Can we conduct the configure check only for the hpux11_64 module? Or do we know that tgetent always returns 0 on that system?

     
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-23

    Logged In: YES
    user_id=1889927
    Originator: YES

    Well, having done ./configure ac_cv_search_tgetent=-lcurses on a solaris, hppa-hpux, ia64-hpux, alpha-osf5.1, mips-irix and x86-linux, it looks like hpux with -lcurses is the only system that needs special treatment. hppa-hpux with -ltermcap tgetent returns 1 for success, with -lcurses it returns 0.

    This issue is documented in the ncurses manpage:
    Neither the XSI Curses standard nor the SVr4 man pages documented the
    return values of tgetent correctly, though all three were in fact
    returned ever since SVr1. In particular, an omission in the XSI Curses
    documentation has been misinterpreted to mean that tgetent returns OK
    or ERR. Because the purpose of these functions is to provide compati-
    bility with the termcap library, that is a defect in XCurses, Issue 4,
    Version 2 rather than in ncurses.

    I can only suggest something like:
    AC_CACHE_CHECK([for 0 return value from tgetent with invalid TERM],
    [top_cv_tgetent_returns_zero_for_bad_term],
    [
    if test "X$ac_cv_search_tgetent" = "X-lcurses"; then
    case "$target_os" in
    hpux*) top_cv_tgetent_returns_zero_for_bad_term=no ;;
    *) top_cv_tgetent_returns_zero_for_bad_term=no ;;
    else
    top_cv_tgetent_returns_zero_for_bad_term=yes
    fi
    ])

     
  • Peter O'Gorman
    Peter O'Gorman
    2008-07-23

    Logged In: YES
    user_id=1889927
    Originator: YES

    sigh:
    AC_CACHE_CHECK([for 0 return value from tgetent with invalid TERM],
    [top_cv_tgetent_returns_zero_for_bad_term],
    [
    if test "X$ac_cv_search_tgetent" = "X-lcurses"; then
    case "$target_os" in
    hpux*) top_cv_tgetent_returns_zero_for_bad_term=no ;;
    *) top_cv_tgetent_returns_zero_for_bad_term=yes ;;
    else
    top_cv_tgetent_returns_zero_for_bad_term=yes
    fi
    ])

     
  • Logged In: YES
    user_id=687210
    Originator: NO

    Okay, I will use the last config script you posted.