Wired binary behavior

Discussion in 'C Programming' started by Kris Garrett, Aug 26, 2007.

  1. Kris Garrett

    Kris Garrett Guest

    On AIX-4.3.3 using xlc v5.0, I observe the following madness:

    int
    main(int argc, char *argv[])
    {
    char ifxsrv[64];

    ProcConfig config;
    FSINFO fs_array[NUM_FS];
    SYSCFG util;
    int rc = 0;
    [..snipped..]
    return 0;

    }

    Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    The program does run to completion, but looks as if it somehow returns
    to a non-valid address. The wired part is that if the above code is
    changed to:

    int
    main(int argc, char *argv[])
    {
    ProcConfig config;
    FSINFO fs_array[NUM_FS];
    SYSCFG util;
    int rc = 0;
    char ifxsrv[64];
    [..snipped..]
    return 0;
    }

    The program runs to completion without coredumping on an illegal
    instruction.

    FSINFO, SYSCGF, and ProcConfig are defined in a separate header file.

    My question is why would the order of declarations effect the stability
    of an executable? Non-deterministic behavior == a bad day.
    Kris Garrett, Aug 26, 2007
    #1
    1. Advertising

  2. In article <>,
    Kris Garrett <> wrote:
    >On AIX-4.3.3 using xlc v5.0, I observe the following madness:


    >Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    >The program does run to completion, but looks as if it somehow returns
    >to a non-valid address. The wired part is that if the above code is
    >changed to:


    >The program runs to completion without coredumping on an illegal
    >instruction.


    >My question is why would the order of declarations effect the stability
    >of an executable? Non-deterministic behavior == a bad day.


    The order of declarations affects, on most implementations, the
    order in which variables are allocated on a stack. Some implementations
    bother to sort by size or by alignment (in hopes of packing better),
    but some just put the variables on a stack either in the order
    declared or in the reverse of the ordered declared.

    Therefore, if you happen to be overwriting an array or before the end
    of an array or writing into free memory, whether you have allocated
    a variable or not in a certain relative location in the code can
    affect exactly what happens to be at the place being overwritten,
    and thus can affect whether you see an obvious crash or not.
    --
    All is vanity. -- Ecclesiastes
    Walter Roberson, Aug 27, 2007
    #2
    1. Advertising

  3. Kris Garrett

    Ark Khasin Guest

    Walter Roberson wrote:
    > In article <>,
    > Kris Garrett <> wrote:
    >> On AIX-4.3.3 using xlc v5.0, I observe the following madness:

    >
    >> Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    >> The program does run to completion, but looks as if it somehow returns
    >> to a non-valid address. The wired part is that if the above code is
    >> changed to:

    >
    >> The program runs to completion without coredumping on an illegal
    >> instruction.

    >
    >> My question is why would the order of declarations effect the stability
    >> of an executable? Non-deterministic behavior == a bad day.

    >
    > The order of declarations affects, on most implementations, the
    > order in which variables are allocated on a stack. Some implementations
    > bother to sort by size or by alignment (in hopes of packing better),
    > but some just put the variables on a stack either in the order
    > declared or in the reverse of the ordered declared.
    >
    > Therefore, if you happen to be overwriting an array or before the end
    > of an array or writing into free memory, whether you have allocated
    > a variable or not in a certain relative location in the code can
    > affect exactly what happens to be at the place being overwritten,
    > and thus can affect whether you see an obvious crash or not.

    If your assessment is correct, so is my claim that arrays on stack are
    evil. This claim had been thoroughly rebuffed in this NG though. :)
    -- Ark
    Ark Khasin, Aug 27, 2007
    #3
  4. "Kris Garrett" <> wrote in message
    news:...
    > On AIX-4.3.3 using xlc v5.0, I observe the following madness:
    >
    > int
    > main(int argc, char *argv[])
    > {
    > char ifxsrv[64];
    >
    > ProcConfig config;
    > FSINFO fs_array[NUM_FS];
    > SYSCFG util;
    > int rc = 0;
    > [..snipped..]
    > return 0;
    >
    > }
    >
    > Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    > The program does run to completion, but looks as if it somehow returns
    > to a non-valid address. The wired part is that if the above code is
    > changed to:

    ....
    > My question is why would the order of declarations effect the stability
    > of an executable? Non-deterministic behavior == a bad day.


    The reason is almost certainly that you're writing outside the bounds of one
    of your arrays. If the arrays are in one order, your program corrupts the
    return address on the stack; if the arrays are in a different order, it
    corrupts some other part of the stack (like your other variables).

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking


    --
    Posted via a free Usenet account from http://www.teranews.com
    Stephen Sprunk, Aug 27, 2007
    #4
  5. Kris Garrett

    Richard Bos Guest

    Ark Khasin <> wrote:

    > Walter Roberson wrote:
    > > In article <>,
    > > Kris Garrett <> wrote:
    > >> On AIX-4.3.3 using xlc v5.0, I observe the following madness:

    > >
    > >> Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    > >> The program does run to completion, but looks as if it somehow returns
    > >> to a non-valid address. The wired part is that if the above code is
    > >> changed to:

    > >
    > >> The program runs to completion without coredumping on an illegal
    > >> instruction.

    > >
    > >> My question is why would the order of declarations effect the stability
    > >> of an executable? Non-deterministic behavior == a bad day.

    > >
    > > The order of declarations affects, on most implementations, the
    > > order in which variables are allocated on a stack. Some implementations
    > > bother to sort by size or by alignment (in hopes of packing better),
    > > but some just put the variables on a stack either in the order
    > > declared or in the reverse of the ordered declared.
    > >
    > > Therefore, if you happen to be overwriting an array or before the end
    > > of an array or writing into free memory, whether you have allocated
    > > a variable or not in a certain relative location in the code can
    > > affect exactly what happens to be at the place being overwritten,
    > > and thus can affect whether you see an obvious crash or not.


    In fact, I would say - as a first, not completely informed guess - that
    somewhere in the OP's [..snipped..] code he scribbles past the end of
    ifxsrv[], the array in question.

    > If your assessment is correct, so is my claim that arrays on stack are
    > evil.


    No, that claim is not correct. Writing past the end of an array is evil,
    regardless of where and how that array is declared.

    Richard
    Richard Bos, Aug 27, 2007
    #5
  6. Kris Garrett

    CBFalconer Guest

    Ark Khasin wrote:
    > Walter Roberson wrote:
    >

    .... snip ...
    >
    >> Therefore, if you happen to be overwriting an array or before the
    >> end of an array or writing into free memory, whether you have
    >> allocated a variable or not in a certain relative location in the
    >> code can affect exactly what happens to be at the place being
    >> overwritten, and thus can affect whether you see an obvious crash
    >> or not.

    >
    > If your assessment is correct, so is my claim that arrays on stack
    > are evil. This claim had been thoroughly rebuffed in this NG though.


    No, the thing that is evil is writing into memory that is not part
    of the destination object.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 27, 2007
    #6
  7. Kris Garrett wrote:
    >
    > On AIX-4.3.3 using xlc v5.0, I observe the following madness:
    >
    > int
    > main(int argc, char *argv[])
    > {
    > char ifxsrv[64];
    >
    > ProcConfig config;
    > FSINFO fs_array[NUM_FS];
    > SYSCFG util;
    > int rc = 0;
    > [..snipped..]
    > return 0;
    >
    > }
    >
    > Results in "Illegal instruction(coredump)" upon exiting (via return 0).
    > The program does run to completion, but looks as if it somehow returns
    > to a non-valid address. The wired part is that if the above code is
    > changed to:
    >
    > int
    > main(int argc, char *argv[])
    > {
    > ProcConfig config;
    > FSINFO fs_array[NUM_FS];
    > SYSCFG util;
    > int rc = 0;
    > char ifxsrv[64];
    > [..snipped..]
    > return 0;
    > }
    >
    > The program runs to completion without coredumping on an illegal
    > instruction.
    >
    > FSINFO, SYSCGF, and ProcConfig are defined in a separate header file.
    >
    > My question is why would the order of declarations effect the stability
    > of an executable? Non-deterministic behavior == a bad day.


    Pure guess, based on lack of any other information...

    What if something caused a buffer overrun in ifxsrv[]? In the
    initial version, the overrun smashes the call stack, while the
    modified version smashes rc.

    One possible test would be to put another array immediately
    before and after ifxsrv's definition, memset them to a known
    value, and then examine those arrays before returning from
    main().

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Aug 27, 2007
    #7
  8. Kris Garrett

    Ark Khasin Guest

    CBFalconer wrote:
    > Ark Khasin wrote:
    >> Walter Roberson wrote:
    >>

    > ... snip ...
    >>> Therefore, if you happen to be overwriting an array or before the
    >>> end of an array or writing into free memory, whether you have
    >>> allocated a variable or not in a certain relative location in the
    >>> code can affect exactly what happens to be at the place being
    >>> overwritten, and thus can affect whether you see an obvious crash
    >>> or not.

    >> If your assessment is correct, so is my claim that arrays on stack
    >> are evil. This claim had been thoroughly rebuffed in this NG though.

    >
    > No, the thing that is evil is writing into memory that is not part
    > of the destination object.
    >

    [Also to Richard Bos]
    Let's face it: we mortals are fallible. When we admit that our errors do
    sometimes go out in the wide world, it's appropriate to think about
    minimizing the impact of an error. IMHO, corrupting the heap is not as
    disastrous as corrupting a stack.

    -- Ark
    Ark Khasin, Aug 27, 2007
    #8
  9. Kris Garrett

    Flash Gordon Guest

    Ark Khasin wrote, On 27/08/07 21:20:
    > CBFalconer wrote:
    >> Ark Khasin wrote:
    >>> Walter Roberson wrote:
    >>>

    >> ... snip ...
    >>>> Therefore, if you happen to be overwriting an array or before the
    >>>> end of an array or writing into free memory, whether you have
    >>>> allocated a variable or not in a certain relative location in the
    >>>> code can affect exactly what happens to be at the place being
    >>>> overwritten, and thus can affect whether you see an obvious crash
    >>>> or not.
    >>> If your assessment is correct, so is my claim that arrays on stack
    >>> are evil. This claim had been thoroughly rebuffed in this NG though.

    >>
    >> No, the thing that is evil is writing into memory that is not part
    >> of the destination object.
    >>

    > [Also to Richard Bos]
    > Let's face it: we mortals are fallible. When we admit that our errors do
    > sometimes go out in the wide world, it's appropriate to think about
    > minimizing the impact of an error. IMHO, corrupting the heap is not as
    > disastrous as corrupting a stack.


    IMHO corrupting either is a complete disaster.
    --
    Flash Gordon
    Flash Gordon, Aug 27, 2007
    #9
  10. Kris Garrett

    CBFalconer Guest

    Ark Khasin wrote:
    >

    .... snip ...
    >
    > Let's face it: we mortals are fallible. When we admit that our
    > errors do sometimes go out in the wide world, it's appropriate to
    > think about minimizing the impact of an error. IMHO, corrupting
    > the heap is not as disastrous as corrupting a stack.


    Not so. Either can (and probably does) cause undefined behaviour,
    which includes giving the expected result.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 27, 2007
    #10
  11. Kris Garrett

    Richard Guest

    Flash Gordon <> writes:

    > Ark Khasin wrote, On 27/08/07 21:20:
    >> CBFalconer wrote:
    >>> Ark Khasin wrote:
    >>>> Walter Roberson wrote:
    >>>>
    >>> ... snip ...
    >>>>> Therefore, if you happen to be overwriting an array or before the
    >>>>> end of an array or writing into free memory, whether you have
    >>>>> allocated a variable or not in a certain relative location in the
    >>>>> code can affect exactly what happens to be at the place being
    >>>>> overwritten, and thus can affect whether you see an obvious crash
    >>>>> or not.
    >>>> If your assessment is correct, so is my claim that arrays on stack
    >>>> are evil. This claim had been thoroughly rebuffed in this NG though.
    >>>
    >>> No, the thing that is evil is writing into memory that is not part
    >>> of the destination object.
    >>>

    >> [Also to Richard Bos]
    >> Let's face it: we mortals are fallible. When we admit that our
    >> errors do sometimes go out in the wide world, it's appropriate to
    >> think about minimizing the impact of an error. IMHO, corrupting the
    >> heap is not as disastrous as corrupting a stack.

    >
    > IMHO corrupting either is a complete disaster.


    Of course. The previous statement is simply ridiculous. The heap could
    hold information as important, if not more so, information than the
    stack. Not only that but the side effects might take an eon to debug
    since it is not immediately apparent - it could manifest itself in one
    of a million undefined ways including incorrect mallocs, deallocs, data
    reads, password caches etc etc etc. It is far more likely, especially
    under the scope of a good debugger, that a prudent programmer would
    notice a stack corruption ESPECIALLY since the stack is invariably
    dedicated its own inspection window in the debuggers I have used.
    Richard, Aug 27, 2007
    #11
  12. Kris Garrett

    Ark Khasin Guest

    Richard wrote:
    > Flash Gordon <> writes:
    >
    >> Ark Khasin wrote, On 27/08/07 21:20:
    >>> CBFalconer wrote:
    >>>> Ark Khasin wrote:
    >>>>> Walter Roberson wrote:
    >>>>>
    >>>> ... snip ...
    >>>>>> Therefore, if you happen to be overwriting an array or before the
    >>>>>> end of an array or writing into free memory, whether you have
    >>>>>> allocated a variable or not in a certain relative location in the
    >>>>>> code can affect exactly what happens to be at the place being
    >>>>>> overwritten, and thus can affect whether you see an obvious crash
    >>>>>> or not.
    >>>>> If your assessment is correct, so is my claim that arrays on stack
    >>>>> are evil. This claim had been thoroughly rebuffed in this NG though.
    >>>> No, the thing that is evil is writing into memory that is not part
    >>>> of the destination object.
    >>>>
    >>> [Also to Richard Bos]
    >>> Let's face it: we mortals are fallible. When we admit that our
    >>> errors do sometimes go out in the wide world, it's appropriate to
    >>> think about minimizing the impact of an error. IMHO, corrupting the
    >>> heap is not as disastrous as corrupting a stack.

    >> IMHO corrupting either is a complete disaster.

    >
    > Of course. The previous statement is simply ridiculous.


    Your righteousness is ridiculous, but in a complex way.

    >The heap could
    > hold information as important, if not more so, information than the
    > stack. Not only that but the side effects might take an eon to debug
    > since it is not immediately apparent - it could manifest itself in one
    > of a million undefined ways including incorrect mallocs, deallocs, data
    > reads, password caches etc etc etc. It is far more likely, especially
    > under the scope of a good debugger, that a prudent programmer would
    > notice a stack corruption ESPECIALLY since the stack is invariably
    > dedicated its own inspection window in the debuggers I have used.

    Bugs don't like bright light; they tend to show up when you are not looking.
    It is not uncommon in critical apps to wrap malloc so as to allocate
    areas with guards on one or both sides.
    Ark Khasin, Aug 29, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anders Borum
    Replies:
    0
    Views:
    3,438
    Anders Borum
    Jun 9, 2004
  2. cschang
    Replies:
    0
    Views:
    453
    cschang
    Apr 5, 2005
  3. Matthias =?ISO-8859-1?Q?G=FCntert?=

    wired md5 hashing problem

    Matthias =?ISO-8859-1?Q?G=FCntert?=, Mar 26, 2006, in forum: Python
    Replies:
    1
    Views:
    332
    Paul Rubin
    Mar 26, 2006
  4. BillE
    Replies:
    2
    Views:
    374
    BillE
    Dec 1, 2006
  5. Replies:
    7
    Views:
    361
    Branimir Maksimovic
    Oct 15, 2005
Loading...

Share This Page