«

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 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-lit...t.html#faq-5.8 in
particular) and post a minimal, compilable version of your code.

Regards,
Sumit.

"Gaurav" <> wrote in message
news: oups.com...
> 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 wrote:
> "Gaurav" <> wrote in message
> news: oups.com...

>> 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_%28cricket%29)
which can also be used to describe anything that's tough to "play". .


</OT>

Howard wrote:
> "Gaurav" <> wrote in message
> news: oups.com...
> > 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" <> wrote in message
news: oups.com...
>
> Howard wrote:
>> "Gaurav" <> wrote in message
>> news: oups.com...

>>
>> 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] = 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 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

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: oups.com...
> >
> > Howard wrote:
> >> "Gaurav" <> wrote in message
> >> news: oups.com...
>
> >>
> >> 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] = 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" <> wrote in message
news: ups.com...
> 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