Diff b/w the working of exe from within the VS and console

Discussion in 'C++' started by Gaurav, Oct 11, 2006.

  1. Gaurav

    Gaurav Guest

    Hi All,

    I have written the 'c' code for specific purpose and tested it over
    many files and it is crashing in only one case. When I ran the same
    code in the debug mode within the VS against the same file it works
    well and it also works well in the release mode with in the VS. It get
    crashed only when I run it from the console.

    I have checked my code against the heap correction and memory leaks and
    its perfectly fine. I have tried every option and none of them is
    working and also if I put up some printf in my code, it start working
    from the console mode.

    In short, this is a bouncer for me.

    Does any one have some ideas how the working of the exe is different
    when we ran it from the VS as comapred to console. or the points whihc
    i should consider regarding my code?


    Thanks
    Gaurav Vashishth
     
    Gaurav, Oct 11, 2006
    #1
    1. Advertising

  2. Gaurav

    Sumit Rajan Guest

    Gaurav wrote:
    > Hi All,
    >
    > I have written the 'c' code for specific purpose and tested it over
    > many files and it is crashing in only one case. When I ran the same
    > code in the debug mode within the VS against the same file it works
    > well and it also works well in the release mode with in the VS. It get
    > crashed only when I run it from the console.
    >
    > I have checked my code against the heap correction and memory leaks and
    > its perfectly fine. I have tried every option and none of them is
    > working and also if I put up some printf in my code, it start working
    > from the console mode.
    >
    > In short, this is a bouncer for me.
    >
    > Does any one have some ideas how the working of the exe is different
    > when we ran it from the VS as comapred to console. or the points whihc
    > i should consider regarding my code?



    Please see the
    FAQ(http://www.parashift.com/c -faq-lite/how-to-post.html#faq-5.8 in
    particular) and post a minimal, compilable version of your code.

    Regards,
    Sumit.
     
    Sumit Rajan, Oct 11, 2006
    #2
    1. Advertising

  3. Gaurav

    Howard Guest

    "Gaurav" <> wrote in message
    news:...
    > Hi All,
    >
    > I have written the 'c' code for specific purpose and tested it over
    > many files and it is crashing in only one case.


    You do know this is a C++ newsgroup, not a C newsgroup, right?

    I'm not sure what you mean when you say you "tested it over many files".
    Are you talking about some kind of input data file your program reads?

    > When I ran the same
    > code in the debug mode within the VS against the same file it works
    > well and it also works well in the release mode with in the VS. It get
    > crashed only when I run it from the console.
    >
    > I have checked my code against the heap correction and memory leaks and
    > its perfectly fine. I have tried every option and none of them is
    > working and also if I put up some printf in my code, it start working
    > from the console mode.
    >
    > In short, this is a bouncer for me.


    "bouncer"? :)

    >
    > Does any one have some ideas how the working of the exe is different
    > when we ran it from the VS as comapred to console. or the points whihc
    > i should consider regarding my code?
    >


    Given that you said it works if you add in printf statements, then a highly
    likely cause is that you're overwriting a buffer (i.e., assigning values to
    positions past the end of an array). Check if your code contains any
    arrays, and make sure that there is no way your code can write past the end
    (including C-string-related code which may tack on a NULL-terminator behind
    the scenes).

    It could be that the file which exhibits the problem has data in it which
    isn't the expected format. For example, you might be expecting CR/LF line
    terminators, but it contains only CR terminators, or none at all. Or some
    line in the file may be one character longer than you expect. Or you may be
    expecting it to be pure ASCII, but it contains a non-ASCII character
    somewhere.

    Of course, without seeing any code, it's impossible for us to tell if you've
    got a logic or coding error somewhere.

    -Howard
     
    Howard, Oct 11, 2006
    #3
  4. Gaurav

    Sumit Rajan Guest

    Howard wrote:
    > "Gaurav" <> wrote in message
    > news:...


    >> In short, this is a bouncer for me.


    >
    > "bouncer"? :)


    <OT>

    Not the nightclub type of bouncer.

    A cricketing term(http://en.wikipedia.org/wiki/Bouncer_(cricket))
    which can also be used to describe anything that's tough to "play". :).


    </OT>
     
    Sumit Rajan, Oct 12, 2006
    #4
  5. Gaurav

    Gaurav Guest

    Howard wrote:
    > "Gaurav" <> wrote in message
    > news:...
    > > Hi All,
    > >
    > > I have written the 'c' code for specific purpose and tested it over
    > > many files and it is crashing in only one case.

    >
    > You do know this is a C++ newsgroup, not a C newsgroup, right?
    >
    > I'm not sure what you mean when you say you "tested it over many files".
    > Are you talking about some kind of input data file your program reads?
    >


    Yes you are right.

    > > When I ran the same
    > > code in the debug mode within the VS against the same file it works
    > > well and it also works well in the release mode with in the VS. It get
    > > crashed only when I run it from the console.
    > >
    > > I have checked my code against the heap correction and memory leaks and
    > > its perfectly fine. I have tried every option and none of them is
    > > working and also if I put up some printf in my code, it start working
    > > from the console mode.
    > >
    > > In short, this is a bouncer for me.

    >
    > "bouncer"? :)
    >
    > >
    > > Does any one have some ideas how the working of the exe is different
    > > when we ran it from the VS as comapred to console. or the points whihc
    > > i should consider regarding my code?
    > >

    >
    > Given that you said it works if you add in printf statements, then a highly
    > likely cause is that you're overwriting a buffer (i.e., assigning values to
    > positions past the end of an array). Check if your code contains any
    > arrays, and make sure that there is no way your code can write past the end
    > (including C-string-related code which may tack on a NULL-terminator behind
    > the scenes).
    >
    > It could be that the file which exhibits the problem has data in it which
    > isn't the expected format. For example, you might be expecting CR/LF line
    > terminators, but it contains only CR terminators, or none at all. Or some
    > line in the file may be one character longer than you expect. Or you may be
    > expecting it to be pure ASCII, but it contains a non-ASCII character
    > somewhere.
    >
    > Of course, without seeing any code, it's impossible for us to tell if you've
    > got a logic or coding error somewhere.
    >


    Well, if I'm overwriting the buffers then my heapcheck test should fail
    but it is not and secondly test file is perfectly ok and it is in the
    binary format

    I'm using this for checking the heap
    _ASSERTE(_CrtCheckMemory());
    heapstatus = _heapchk();


    > -Howard
     
    Gaurav, Oct 12, 2006
    #5
  6. Gaurav

    Howard Guest

    "Gaurav" <> wrote in message
    news:...
    >
    > Howard wrote:
    >> "Gaurav" <> wrote in message
    >> news:...


    >>
    >> Given that you said it works if you add in printf statements, then a
    >> highly
    >> likely cause is that you're overwriting a buffer (i.e., assigning values
    >> to
    >> positions past the end of an array). Check if your code contains any
    >> arrays, and make sure that there is no way your code can write past the
    >> end
    >> (including C-string-related code which may tack on a NULL-terminator
    >> behind
    >> the scenes).
    >>
    >> It could be that the file which exhibits the problem has data in it which
    >> isn't the expected format. For example, you might be expecting CR/LF
    >> line
    >> terminators, but it contains only CR terminators, or none at all. Or
    >> some
    >> line in the file may be one character longer than you expect. Or you may
    >> be
    >> expecting it to be pure ASCII, but it contains a non-ASCII character
    >> somewhere.
    >>
    >> Of course, without seeing any code, it's impossible for us to tell if
    >> you've
    >> got a logic or coding error somewhere.
    >>

    >
    > Well, if I'm overwriting the buffers then my heapcheck test should fail
    > but it is not and secondly test file is perfectly ok and it is in the
    > binary format
    >
    > I'm using this for checking the heap
    > _ASSERTE(_CrtCheckMemory());
    > heapstatus = _heapchk();
    >


    I'm not positive, but I don't think that a "heap check" will tell you if you
    wrote past the end of a locally declared array. I think that has to do with
    dynamic memory allocation. I'm talking about writing past the end of local
    (or possibly even member) arrays, such as this:

    int arr[10];
    for (int i = 0; i <= 10; ++i)
    arr = i;

    That will write 10 at arr[10], which is illegal (specifically, it's
    "Undefined Behavior").

    Writing past the end of an array simply puts new values in locations which
    may or may not be ok to write in. And from a lot of experience, I can say
    that this is probably the most likely kind of error to exhibit the behavior
    you describe.

    The reason buffer overruns exhibit this behavior is that when you add other
    code (such as a printf), or run within a debugger, what resides in the
    memory immediately after a local array is likely to be different, so the
    behavior when changing those memory locations is different. Everything may
    be fine for your testing, but one or more customers may complain about
    crashes. The crashing may appear random, or may happen whenever a specific
    set of actions is taken or specific data is used. And it often crashes at a
    location in the code that has nothing to do with the code that overwrote the
    array.

    Every thing you've described about the symptoms fits this pattern. I
    strongly suggest that you check out the code carefully. (Also, you might
    want to isolate portions of the code and test their boundary conditions
    thoroughly, with unit tests.)

    Another possibility is using uninitialized variables, or dereferencing
    pointers after they've been deleted.

    I've given you the most likely culprit(s). So now it's up to you: either
    post code which exhibits the problem, or find the problem yourself. Nobody
    here can simply guess what's wrong, especially if you're just going to
    respond that we've guessed wrong.

    -Howard
     
    Howard, Oct 12, 2006
    #6
  7. Gaurav

    Puppet_Sock Guest

    Gaurav wrote:
    [snip]
    > Well, if I'm overwriting the buffers then my heapcheck test should fail
    > but it is not and secondly test file is perfectly ok and it is in the
    > binary format


    Maybe, maybe not. Heapcheck tests cannot be perfect.

    Consider something like the following snippet.

    char someChars = new char[10];
    integer someInts = new int[10];

    // ... stuff happens

    someChars[12] = 'c';

    Maybe this gets caught by a heapcheck test. Maybe it simply
    corrupts the "stuff" involved in keeping track of where these
    memory allocs have been put in memory. Maybe it just messes
    up the contents of someInts. It's really not possible to say what
    will happen. But it's quite highly likely it won't be good.
    Socks
     
    Puppet_Sock, Oct 12, 2006
    #7
  8. Gaurav

    Gaurav Guest

    Thanks for your suggestion, I have figured out my problem. It was
    buffer overwriting.

    But still I have one doubt, when we execute the code in the debug mode
    the compiler writes the four byte, fd fd fd fd, at the end of every
    buffer and this is what heapcheck performs. It checks that whether the
    four bytes padding after every buffer is there or not and it intimate
    us accordingly.

    Then how my heapchek functions not able to locate my problem

    Reards,
    Gaurav

    Howard wrote:
    > "Gaurav" <> wrote in message
    > news:...
    > >
    > > Howard wrote:
    > >> "Gaurav" <> wrote in message
    > >> news:...

    >
    > >>
    > >> Given that you said it works if you add in printf statements, then a
    > >> highly
    > >> likely cause is that you're overwriting a buffer (i.e., assigning values
    > >> to
    > >> positions past the end of an array). Check if your code contains any
    > >> arrays, and make sure that there is no way your code can write past the
    > >> end
    > >> (including C-string-related code which may tack on a NULL-terminator
    > >> behind
    > >> the scenes).
    > >>
    > >> It could be that the file which exhibits the problem has data in it which
    > >> isn't the expected format. For example, you might be expecting CR/LF
    > >> line
    > >> terminators, but it contains only CR terminators, or none at all. Or
    > >> some
    > >> line in the file may be one character longer than you expect. Or you may
    > >> be
    > >> expecting it to be pure ASCII, but it contains a non-ASCII character
    > >> somewhere.
    > >>
    > >> Of course, without seeing any code, it's impossible for us to tell if
    > >> you've
    > >> got a logic or coding error somewhere.
    > >>

    > >
    > > Well, if I'm overwriting the buffers then my heapcheck test should fail
    > > but it is not and secondly test file is perfectly ok and it is in the
    > > binary format
    > >
    > > I'm using this for checking the heap
    > > _ASSERTE(_CrtCheckMemory());
    > > heapstatus = _heapchk();
    > >

    >
    > I'm not positive, but I don't think that a "heap check" will tell you if you
    > wrote past the end of a locally declared array. I think that has to do with
    > dynamic memory allocation. I'm talking about writing past the end of local
    > (or possibly even member) arrays, such as this:
    >
    > int arr[10];
    > for (int i = 0; i <= 10; ++i)
    > arr = i;
    >
    > That will write 10 at arr[10], which is illegal (specifically, it's
    > "Undefined Behavior").
    >
    > Writing past the end of an array simply puts new values in locations which
    > may or may not be ok to write in. And from a lot of experience, I can say
    > that this is probably the most likely kind of error to exhibit the behavior
    > you describe.
    >
    > The reason buffer overruns exhibit this behavior is that when you add other
    > code (such as a printf), or run within a debugger, what resides in the
    > memory immediately after a local array is likely to be different, so the
    > behavior when changing those memory locations is different. Everything may
    > be fine for your testing, but one or more customers may complain about
    > crashes. The crashing may appear random, or may happen whenever a specific
    > set of actions is taken or specific data is used. And it often crashes at a
    > location in the code that has nothing to do with the code that overwrote the
    > array.
    >
    > Every thing you've described about the symptoms fits this pattern. I
    > strongly suggest that you check out the code carefully. (Also, you might
    > want to isolate portions of the code and test their boundary conditions
    > thoroughly, with unit tests.)
    >
    > Another possibility is using uninitialized variables, or dereferencing
    > pointers after they've been deleted.
    >
    > I've given you the most likely culprit(s). So now it's up to you: either
    > post code which exhibits the problem, or find the problem yourself. Nobody
    > here can simply guess what's wrong, especially if you're just going to
    > respond that we've guessed wrong.
    >
    > -Howard
     
    Gaurav, Oct 12, 2006
    #8
  9. Gaurav

    Howard Guest

    "Gaurav" <> wrote in message
    news:...
    > Thanks for your suggestion, I have figured out my problem. It was
    > buffer overwriting.
    >
    > But still I have one doubt, when we execute the code in the debug mode
    > the compiler writes the four byte, fd fd fd fd, at the end of every
    > buffer and this is what heapcheck performs. It checks that whether the
    > four bytes padding after every buffer is there or not and it intimate
    > us accordingly.
    >
    > Then how my heapchek functions not able to locate my problem
    >
    > Reards,
    > Gaurav
    >


    HI Guarav,

    please don't top-post. Replies belong either below or interspersed with
    what you're responding to, ok? Thanks.

    I'm glad I could help. The symptoms sounded like a buffer overwrite,
    and it turns out it was.

    I don't know exactly how that heap check tool works, or what the
    contents of your memory looks like before and after you write past the end,
    but apparently the heap check isn't catching it. You could write their tech
    support and ask them why not, I suppose.

    Regards,
    Howard
     
    Howard, Oct 12, 2006
    #9
    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. Cyril Vi?ville

    diff Process under diff users

    Cyril Vi?ville, Jun 29, 2004, in forum: Perl
    Replies:
    1
    Views:
    518
    Joe Smith
    Jun 29, 2004
  2. Berrucho
    Replies:
    2
    Views:
    656
    Infant Newbie
    Dec 5, 2003
  3. A Traveler

    Diff CSS styles for diff INPUT TYPE='s?

    A Traveler, Aug 31, 2004, in forum: ASP .Net
    Replies:
    6
    Views:
    4,942
    Steve Fulton
    Aug 31, 2004
  4. Chaos
    Replies:
    1
    Views:
    423
  5. Austin Ziegler

    [ANN] Diff::LCS 1.1.0, Diff::LCS 1.0.4

    Austin Ziegler, Aug 8, 2004, in forum: Ruby
    Replies:
    3
    Views:
    201
    Austin Ziegler
    Aug 9, 2004
Loading...

Share This Page