Porting Tru64 to HP-UX - Unix

This is a discussion on Porting Tru64 to HP-UX - Unix ; Hello All Encountered a problem when recompiling working production code from a Alpha Tru64 platform on an Itanium HP-UX platform. The problem seems to be related to how I am using NULL, have read the man pages but are unable ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Porting Tru64 to HP-UX

  1. Porting Tru64 to HP-UX

    Hello All

    Encountered a problem when recompiling working production code from a
    Alpha Tru64 platform on an Itanium HP-UX platform.

    The problem seems to be related to how I am using NULL, have read the
    man pages but are unable to determine exactly why I am experiencing
    this problem. Below is a code extract, the process core dump, SEGV, at
    the point where I do this rulePtr->prev = NULL

    Can anyone please shed some light on this behaviour.

    Thank you,

    B

    struct RemRule
    {
    int remId;
    REMPtabevent_t event;
    struct RemRule *prev;
    struct RemRule *next;
    };


    GR_t mapData(REMRULE *remRule)
    {
    int i = 0;
    REMRULE *rulePtr;
    char buff[20];

    rulePtr = (REMRULE*) calloc(1, sizeof(REMRULE));

    if(rulePtr == NULL)
    return GERfail_e;

    rulePtr->prev = NULL;
    rulePtr->next = NULL;

    ....
    }

  2. Re: Porting Tru64 to HP-UX

    bcpkh wrote:
    > Hello All


    > Encountered a problem when recompiling working production code from
    > a Alpha Tru64 platform on an Itanium HP-UX platform.


    > The problem seems to be related to how I am using NULL, have read
    > the man pages but are unable to determine exactly why I am
    > experiencing this problem. Below is a code extract, the process core
    > dump, SEGV, at the point where I do this rulePtr->prev = NULL


    > Can anyone please shed some light on this behaviour.


    > Thank you,


    > B


    > struct RemRule
    > {
    > int remId;
    > REMPtabevent_t event;
    > struct RemRule *prev;
    > struct RemRule *next;
    > };



    > GR_t mapData(REMRULE *remRule)
    > {
    > int i = 0;
    > REMRULE *rulePtr;
    > char buff[20];


    > rulePtr = (REMRULE*) calloc(1, sizeof(REMRULE));


    > if(rulePtr == NULL)
    > return GERfail_e;


    > rulePtr->prev = NULL;
    > rulePtr->next = NULL;


    > ....
    > }


    Can you post a more complete example?

    Is this straight cut-and-paste, or a re-type? Any chance it reads:

    if (rulePtr = NULL)
    return GERfail_e;

    I got burned by bugs like that enough in the past that I've gotten
    into the habit of putting the constants first:

    if (NULL == rulePtr)
    return GERfail_e;

    to help let the compiler tell me when I've messed-up and used "="
    instead of "==".

    I still waffle on whether it should be

    if (NULL == rulePtr)
    return GERfail_e;

    or

    if (NULL == rulePtr) {
    return GERfail_e;
    }

    to protect myself against forgetfulness when I add to the code to be
    executed when the if evaluates to true and forget to add the curly
    braces.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: Porting Tru64 to HP-UX

    bcpkh wrote:
    > Hello All
    >
    > Encountered a problem when recompiling working production code from a
    > Alpha Tru64 platform on an Itanium HP-UX platform.
    >
    > The problem seems to be related to how I am using NULL, have read the
    > man pages but are unable to determine exactly why I am experiencing
    > this problem. Below is a code extract, the process core dump, SEGV, at
    > the point where I do this rulePtr->prev = NULL
    >
    > Can anyone please shed some light on this behaviour.


    Nothing certain, but I'll raise a few points you might
    want to check.

    > struct RemRule
    > {
    > int remId;
    > REMPtabevent_t event;
    > struct RemRule *prev;
    > struct RemRule *next;
    > };
    >
    >
    > GR_t mapData(REMRULE *remRule)


    What's a REMRULE? Is it a typedef for struct RemRule,
    or a #define, or what? I imagine it's intended, one way
    or another, to turn into a struct RemRule eventually, but
    does it truly do so?

    > {
    > int i = 0;
    > REMRULE *rulePtr;
    > char buff[20];
    >
    > rulePtr = (REMRULE*) calloc(1, sizeof(REMRULE));


    Have you forgotten to #include ? (This seems
    to me the most likely possibility.)

    > if(rulePtr == NULL)
    > return GERfail_e;


    Any chance that the actual code uses = where == was
    intended? That would cause a good, hard crash ...

    > rulePtr->prev = NULL;
    > rulePtr->next = NULL;
    >
    > ....
    > }


    If you check out the three points above and don't find a
    smoking gun, my next guess would be that the program has
    previously corrupted the heap, causing calloc to misbehave.
    Maybe it's free'd something twice, or free'd something that
    wasn't obtained from malloc et al., or allowed a pointer to
    run off the end of an allocated area and trample a neighbor,
    or something of that nature. Unfortunately, the fact that
    a program has been working for a long time doesn't mean it's
    bug-free; it may just mean it's been lucky.

    --
    Eric.Sosman@sun.com

  4. Re: Porting Tru64 to HP-UX

    Hay Rick

    Below an actual cut and paste of the working code (Tru64), function
    mapRuleData shortened;

    Header file;
    #ifndef REMRULES_H
    #define REMRULES_H

    #include "oci.h"
    #include "RREJrejectEventModify.h"

    struct RemRule
    {
    int remId;
    char ruleType[32];
    char ruleName[41];
    sb2 ruleName_ind;
    char ruleProcedure[64];
    sb2 ruleProcedure_ind;
    int matchCount;
    int modifiedCount;
    int plSqlError;
    char eventDtm[20];
    sb2 eventDtm_ind;
    REMPtabRejectevent_t rejectevent;
    struct RemRule *prev;
    struct RemRule *next;
    };

    typedef struct RemRule REMRULE;

    GER_t getRemRules();
    GER_t mapRuleData(REMRULE *remRule);
    GER_t freeRuleData();

    #endif

    C source;
    GER_t mapRuleData(REMRULE *remRule)
    {
    int i = 0;
    REMRULE *rulePtr;
    char buff[20];

    rulePtr = (REMRULE*) calloc(1, sizeof(REMRULE));

    if(rulePtr == NULL)
    return GERfail_e;

    rulePtr->prev = NULL;
    rulePtr->next = NULL;

    if(ruleHeadPtr == NULL) //Set the list head Ptr
    ruleHeadPtr = rulePtr;

    if(ruleTailPtr == NULL)
    ruleTailPtr = rulePtr;
    else
    {
    ruleTailPtr->next = rulePtr;
    rulePtr->prev = ruleTailPtr;
    ruleTailPtr = rulePtr;
    }
    ...
    }

  5. Re: Porting Tru64 to HP-UX

    bcpkh wrote:
    > Hay Rick


    > Below an actual cut and paste of the working code (Tru64), function
    > mapRuleData shortened;


    > Header file;
    > #ifndef REMRULES_H
    > #define REMRULES_H


    > #include "oci.h"
    > #include "RREJrejectEventModify.h"


    > struct RemRule
    > {
    > int remId;
    > char ruleType[32];
    > char ruleName[41];
    > sb2 ruleName_ind;
    > char ruleProcedure[64];
    > sb2 ruleProcedure_ind;
    > int matchCount;
    > int modifiedCount;
    > int plSqlError;
    > char eventDtm[20];
    > sb2 eventDtm_ind;
    > REMPtabRejectevent_t rejectevent;
    > struct RemRule *prev;
    > struct RemRule *next;
    > };


    Probably a long shot and this will show me to be far from a compiler
    type, but were there any warnings from the compiler about alignment?
    I'm not sure what size an sb2 might be, but seeing things like char
    ruleName[41] makes me wonder if perhaps prev and next aren't correctly
    aligned in the memory you calloc. I'd have expected the compiler to
    align them correctly, but if there were some pragmas somewhere else
    who knows...

    If things don't pan-out here, there is always comp.sys.hp.hpux, or the
    cxx-dev mailing list at cxx.cup.hp.com. I suspect that the folks
    there will ask things like which rev of UX, which rev of the compiler
    etc etc...

    > typedef struct RemRule REMRULE;


    > GER_t getRemRules();
    > GER_t mapRuleData(REMRULE *remRule);
    > GER_t freeRuleData();


    > #endif


    > C source;
    > GER_t mapRuleData(REMRULE *remRule)
    > {
    > int i = 0;
    > REMRULE *rulePtr;
    > char buff[20];


    > rulePtr = (REMRULE*) calloc(1, sizeof(REMRULE));


    > if(rulePtr == NULL)
    > return GERfail_e;


    Being a luddite and a firm believer in creating mnemonic memory
    circuits from stone knives and bearskins, I'd put-in some diagnositc
    printf's to print-out the address of rulePtr->prev and rulePtr->next
    to make sure they were on either four (32-bit) or eight (64-bit) byte
    alignment after the calloc.

    > rulePtr->prev = NULL;
    > rulePtr->next = NULL;


    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  6. Re: Porting Tru64 to HP-UX

    Hello all

    Thank you for the help and 'pointers', explicitly including stdlib.h
    solved my core dump. I removed the cast of the calloc return value and
    the compiler complained about an invalid assignment int to * including
    stdlib.h silenced the compiler and solved the problem.

    Now a bit of education please, why was this never a problem when the
    process was running under Tru64? What other issues can one run into by
    not including stdlib.h, only memory allocation errors?

    Thank you,

    B

  7. Re: Porting Tru64 to HP-UX

    bcpkh writes:

    > Hello all
    >
    > Thank you for the help and 'pointers', explicitly including stdlib.h
    > solved my core dump. I removed the cast of the calloc return value and
    > the compiler complained about an invalid assignment int to * including
    > stdlib.h silenced the compiler and solved the problem.
    >
    > Now a bit of education please, why was this never a problem when the
    > process was running under Tru64?


    You probably got lucky, and calloc() returned an address with the
    upper 32 bits all zero.

    > What other issues can one run into by not including stdlib.h, only
    > memory allocation errors?


    Don't push fate, just include the header.

    --
    Måns Rullgård
    mans@mansr.com

  8. Re: Porting Tru64 to HP-UX

    Måns Rullgård wrote:
    > bcpkh writes:
    >
    >> Hello all
    >>
    >> Thank you for the help and 'pointers', explicitly including stdlib.h
    >> solved my core dump. I removed the cast of the calloc return value and
    >> the compiler complained about an invalid assignment int to * including
    >> stdlib.h silenced the compiler and solved the problem.
    >>
    >> Now a bit of education please, why was this never a problem when the
    >> process was running under Tru64?

    >
    > You probably got lucky, and calloc() returned an address with the
    > upper 32 bits all zero.


    Or perhaps the headers that were used contained lots
    of #ifdefs and things, taking different paths on Tru64 and
    on the new environment and including under the
    former while omitting it under the latter.

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

  9. Re: Porting Tru64 to HP-UX

    On Wed, 09 Apr 2008 08:35:44 -0400, Eric Sosman wrote:

    > Måns Rullgård wrote:
    >> bcpkh writes:
    >>


    > Or perhaps the headers that were used contained lots
    > of #ifdefs and things, taking different paths on Tru64 and on the new
    > environment and including under the former while omitting it
    > under the latter.


    That seems a reasonable mechanism. The TRU64 compiler is, even without
    flags, very picky (for obvious reasons):

    moi> cat hup.c

    struct hup {
    int i;
    struct hup *nxt;
    } *hpp;
    main()
    {
    hpp = calloc (1, sizeof *hpp);
    }

    moi> cc hup.c
    cc: Warning: hup.c, line 8: In this statement, "calloc(...)" of type
    "int", is being converted to "pointer to struct hup".
    hpp = calloc (1, sizeof *hpp);
    ^
    moi> cc -V
    cc (cc)
    Digital UNIX Compiler Driver 3.11
    DEC C V5.6-071 on Digital UNIX V4.0 (Rev. 878)
    /usr/lib/cmplrs/cc/ld: /* snipped */


    This happens even in -std0 (K&R) mode.
    AvK

  10. Re: Porting Tru64 to HP-UX

    On Wed, 09 Apr 2008 14:52:52 +0200, moi wrote:


    > This happens even in -std0 (K&R) mode.


    Well,the message is, of course, suppressed by adding the cast.

    AvK

  11. Re: Porting Tru64 to HP-UX

    M?ns Rullg?rd wrote:
    > bcpkh writes:
    > > Thank you for the help and 'pointers', explicitly including
    > > stdlib.h solved my core dump. I removed the cast of the calloc
    > > return value and the compiler complained about an invalid
    > > assignment int to * including stdlib.h silenced the compiler and
    > > solved the problem.


    The compiler warns for a reason Now, sometimes the compiler doesn't
    have all that good a reason, but still, if it goes to the trouble to
    emit a warning, best to pay it heed.

    Particularly when you are using explicit flags to get 64-bit
    compilation, as one must do to get 64-bits on HP-UX. There are IIRC
    some additional flags one can add to have the compiler look for more
    32 vs 64 bit warnings that you might have dodged on Alpha. You might
    also look into cadvise:

    http://www.hp.com/go/cadvise

    > > Now a bit of education please, why was this never a problem when
    > > the process was running under Tru64?


    > You probably got lucky, and calloc() returned an address with the
    > upper 32 bits all zero.


    Indeed, my recollection is that I heard that the addresses one would
    get would start at levels where they would "fit" in 32 bits.

    > > What other issues can one run into by not including stdlib.h, only
    > > memory allocation errors?


    > Don't push fate, just include the header.


    And pay attention to compiler warnings

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  12. Re: Porting Tru64 to HP-UX

    Rick Jones writes:

    > M?ns Rullg?rd wrote:
    >> bcpkh writes:
    >> > Now a bit of education please, why was this never a problem when
    >> > the process was running under Tru64?

    >
    >> You probably got lucky, and calloc() returned an address with the
    >> upper 32 bits all zero.

    >
    > Indeed, my recollection is that I heard that the addresses one would
    > get would start at levels where they would "fit" in 32 bits.


    Not in general. There is the -taso flag, however, which requests that
    addresses be 32-bit only. It doesn't change the size of pointers,
    only restricts the range of addresses used. This was added to the
    compiler/linker to aid porting broken apps.

    --
    Måns Rullgård
    mans@mansr.com

+ Reply to Thread