Corruption in Montavista and not in RedHat

[karthikbalaguru]

Hi,

Consider that the below function returns the processed
output in pContent->load[6].
checkfun(&ipdat, (unsigned char *)&pC->load[6]);
If i call the above function inside a module(function),
data returned in 'pC->load[6]' appears to be corrupted in
Montavista Linux / Fedora Core(Vmware) but the data
appears to be intact in RedHat.
That is, it is working with Redhat and not with
Montavista Linux / Fedora Core(Vmware).

But, if i call the same function by allocating some
memory for collecting the output, then the output
returned in that particular variable/buffer appears to
be intact/correct for Montavista Linux / Fedora
Core(Vmware).
For example, the below changes give uncorrupted
data / output in 'bufConent'
char * bufContent = malloc(100);
checkfun(&ipdat, bufContent);
free(bufContent);

Strange !! How is it possible ?
Where could the problem be ?

Thx in advans,
Karthik Balaguru

 

[karthikbalaguru]

Hi,

Consider that the below function returns the processed
output in pContent->load[6].

It should be pC->load[6] and it is not pContent->load[6].

checkfun(&ipdat, (unsigned char *)&pC->load[6]);

Either you're a careless typist, or you're using global
variables much too freely.

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

The important issue, though, is that you have not shown
us what pContent/pC points to: We don't know the type of the
`load' element, except that we can infer it must be either a
pointer or an array, but to what type? And is there any
reason to believe that the [6] element exists? And just how
does checkfun() produce "processed output?"

It is an algorithm that we use for getting the processed output
and hence did not refer to it.
But, Are there any specific set of C code that
will work in Redhat linux and not in Montavista Linux.
How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

[... "works," "doesn't work," ...]
Strange !! How is it possible ?

Because a mistake has been made. Undefined behavior has
probably been at work somewhere along the line.

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

Thx in advans,
Karthik Balaguru

 

[Guest]

karthikbalaguru wrote:

[... "works," "doesn't work," ...]
Strange !! How is it possible ?

     Because a mistake has been made.  Undefined behavior has
probably been at work somewhere along the line.

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

which bit of -

"Because a mistake has been made. Undefined behavior has
probably been at work somewhere along the line."

- didn't you understand?

If you just post snippets of code we haven't a hope in hell
of guessing where your problem might be.

If you are using code that has platform specific
behviour you need to ask on a platform specific
news group (eg. a unix one). And *they* are also
going to want to see your code.

 

[Nate Eldredge]

Hi,

Consider that the below function returns the processed
output in pContent->load[6].

It should be pC->load[6] and it is not pContent->load[6].

checkfun(&ipdat, (unsigned char *)&pC->load[6]);

Either you're a careless typist, or you're using global
variables much too freely.

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

There are lots of possible reasons. Most likely is that there is some
bug in your program, and a difference in system software (kernel,
library or compiler versions or configuration) means that on one system
the bug happens not to cause a problem, but on the other one it does.

For instance, it could be that &pC->load[6] is pointing to some
incorrect address. On Montavista perhaps the memory where it points
actually contains some other data which is being changed at the same
time. On Redhat, it could be that due to a different memory layout the
memory where it points is something that isn't being changed, so you
don't see the corruption. But many other possibilities exist too.

I'd recommend debugging your code on the system where it breaks, since
that should make the bug easier to find. Once you know what is wrong,
you can examine with a debugger just what is occuring on the other
system, if you really want to know why it happens to work there. That
isn't very useful information though, although it could be fun.

If you can't find the bug, posting the source to a complete program
(stripped down if possible) that compiles and exhibits the problem would
let people on this newsgroup who are so inclined try to help you. I'll
warn you, though, that by posting to comp.lang.c, you will probably get a
lot of responses pointing out parts of your program that aren't legal or
result in "undefined behavior" according to the C language standard,
even though they may be perfectly legal on your particular Linux
systems, and have nothing to do with your problem. You may find
comp.os.linux.development.apps or comp.unix.programmer better in this
regard, though they also have a lower readership.

The important issue, though, is that you have not shown
us what pContent/pC points to: We don't know the type of the
`load' element, except that we can infer it must be either a
pointer or an array, but to what type? And is there any
reason to believe that the [6] element exists? And just how
does checkfun() produce "processed output?"

It is an algorithm that we use for getting the processed output
and hence did not refer to it.
But, Are there any specific set of C code that
will work in Redhat linux and not in Montavista Linux.

Possibly. It isn't likely that you're encountering them, so I'm not
going to blindly list possibilities. More likely you have some bug that
is wrong on both systems but by sheer luck doesn't fail on one of them.

 

[John Bode]

Hi,

Consider that the below function returns the processed
output in pContent->load[6].
checkfun(&ipdat, (unsigned char *)&pC->load[6]);
If i call the above function inside a module(function),
data returned in 'pC->load[6]' appears to be corrupted in
Montavista Linux / Fedora Core(Vmware) but the data
appears to be intact in RedHat.
That is, it is working with Redhat and not with
Montavista Linux / Fedora Core(Vmware).

But, if i call the same function by allocating some
memory for collecting the output, then the output
returned in that particular variable/buffer appears to
be intact/correct for Montavista Linux / Fedora
Core(Vmware).
For example, the below changes give uncorrupted
data / output in 'bufConent'
char * bufContent = malloc(100);
checkfun(&ipdat, bufContent);
free(bufContent);

Strange !! How is it possible ?
Where could the problem be ?

Thx in advans,
Karthik Balaguru

What is the type of the load array? Based on what you've written
here, it sounds like your load array isn't properly typed for the
information you're trying to write. The fact that it "works" on
RedHat as opposed to Montavista could be due to type sizes varying
between platforms (e.g., 2- vs. 4-byte ints), different alignment
restrictions, or any number of other issues.

 

[Eric Sosman]

[... not showing any code ...]

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

"Because of the mistake on line 42." That's the best
I can do at the moment; the bank foreclosed on my crystal
ball.

 

[CBFalconer]

[... not showing any code ...]

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

"Because of the mistake on line 42." That's the best I can do at
the moment; the bank foreclosed on my crystal ball.

I suspect they damaged it. I bought one at a foreclosure sale, and
it doesn't work for me. So I have no reason to disagree with 'line
42'.

 

[Gary M. Stewart]

[... not showing any code ...]

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

"Because of the mistake on line 42." That's the best I can do at
the moment; the bank foreclosed on my crystal ball.

I suspect they damaged it. I bought one at a foreclosure sale, and
it doesn't work for me. So I have no reason to disagree with 'line
42'.

Can you see the Lizard People?
Are they reptilian like?

 

[karthikbalaguru]

karthikbalaguru wrote:
Hi,
Consider that the below function returns the processed
output in pContent->load[6].

It should be pC->load[6] and it is not pContent->load[6].

checkfun(&ipdat, (unsigned char *)&pC->load[6]);
Either you're a careless typist, or you're using global
variables much too freely.

But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

There are lots of possible reasons. Most likely is that there is some
bug in your program, and a difference in system software (kernel,
library or compiler versions or configuration) means that on one system
the bug happens not to cause a problem, but on the other one it does.

For instance, it could be that &pC->load[6] is pointing to some
incorrect address. On Montavista perhaps the memory where it points
actually contains some other data which is being changed at the same
time. On Redhat, it could be that due to a different memory layout the
memory where it points is something that isn't being changed, so you
don't see the corruption. But many other possibilities exist too.

I'd recommend debugging your code on the system where it breaks, since
that should make the bug easier to find. Once you know what is wrong,
you can examine with a debugger just what is occuring on the other
system, if you really want to know why it happens to work there. That
isn't very useful information though, although it could be fun.

If you can't find the bug, posting the source to a complete program
(stripped down if possible) that compiles and exhibits the problem would
let people on this newsgroup who are so inclined try to help you. I'll
warn you, though, that by posting to comp.lang.c, you will probably get a
lot of responses pointing out parts of your program that aren't legal or
result in "undefined behavior" according to the C language standard,
even though they may be perfectly legal on your particular Linux
systems, and have nothing to do with your problem. You may find
comp.os.linux.development.apps or comp.unix.programmer better in this
regard, though they also have a lower readership.

The important issue, though, is that you have not shown
us what pContent/pC points to: We don't know the type of the
`load' element, except that we can infer it must be either a
pointer or an array, but to what type? And is there any
reason to believe that the [6] element exists? And just how
does checkfun() produce "processed output?"

It is an algorithm that we use for getting the processed output
and hence did not refer to it.
But, Are there any specific set of C code that
will work in Redhat linux and not in Montavista Linux.

Possibly. It isn't likely that you're encountering them, so I'm not
going to blindly list possibilities. More likely you have some bug that
is wrong on both systems but by sheer luck doesn't fail on one of them.

The above was a code snippet(modified)
to define the problem in few lines.

Actually, I am working with AES algorithm.
I got AES CTR code(RFC 3686) from the below link -
http://fp.gladman.plus.com/AES/index.htm.
I use C language.

On Analysis, i find that in Montavista
1) AES works well and does not affect stack &
local variables if we call from the main or
from an API that inturn calls AES in MontaVista.
main -> AES
main -> API_1 -> AES

2) But, if we have an AES invokation as below
in MontaVista, though it is working, it is
corrupting the stack & local variables and
hence the it is affecting other functionalities.
main -> API_1 -> API_2 ->AES

3) Without AES in MontaVista, i am able to goto
greater stack depths that are much greater than below.
main -> API_1 -> API_2 -> API_3 -> AIP_4

But, In RedHat, AES does not corrupt the stack for all
the above scenarios. Why does AES corrupt the Stack in
Fedora Core alone ? Any ideas ?

Thx in advans,
Karthik Balaguru

 

[karthikbalaguru]

karthikbalaguru wrote:
Hi,
Consider that the below function returns the processed
output in pContent->load[6].
It should be pC->load[6] and it is not pContent->load[6].
checkfun(&ipdat, (unsigned char *)&pC->load[6]);
Either you're a careless typist, or you're using global
variables much too freely.
But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?

There are lots of possible reasons. Most likely is that there is some
bug in your program, and a difference in system software (kernel,
library or compiler versions or configuration) means that on one system
the bug happens not to cause a problem, but on the other one it does.

For instance, it could be that &pC->load[6] is pointing to some
incorrect address. On Montavista perhaps the memory where it points
actually contains some other data which is being changed at the same
time. On Redhat, it could be that due to a different memory layout the
memory where it points is something that isn't being changed, so you
don't see the corruption. But many other possibilities exist too.

I'd recommend debugging your code on the system where it breaks, since
that should make the bug easier to find. Once you know what is wrong,
you can examine with a debugger just what is occuring on the other
system, if you really want to know why it happens to work there. That
isn't very useful information though, although it could be fun.

If you can't find the bug, posting the source to a complete program
(stripped down if possible) that compiles and exhibits the problem would
let people on this newsgroup who are so inclined try to help you. I'll
warn you, though, that by posting to comp.lang.c, you will probably get a
lot of responses pointing out parts of your program that aren't legal or
result in "undefined behavior" according to the C language standard,
even though they may be perfectly legal on your particular Linux
systems, and have nothing to do with your problem. You may find
comp.os.linux.development.apps or comp.unix.programmer better in this
regard, though they also have a lower readership.

The important issue, though, is that you have not shown
us what pContent/pC points to: We don't know the type of the
`load' element, except that we can infer it must be either a
pointer or an array, but to what type? And is there any
reason to believe that the [6] element exists? And just how
does checkfun() produce "processed output?"
It is an algorithm that we use for getting the processed output
and hence did not refer to it.
But, Are there any specific set of C code that
will work in Redhat linux and not in Montavista Linux.

Possibly. It isn't likely that you're encountering them, so I'm not
going to blindly list possibilities. More likely you have some bug that
is wrong on both systems but by sheer luck doesn't fail on one of them.

The above was a code snippet(modified)
to define the problem in few lines.

Actually, I am working with AES algorithm.
I got AES CTR code(RFC 3686) from the below link -http://fp.gladman.plus.com/AES/index.htm.
I use C language.

On Analysis, i find that in Montavista
1) AES works well and does not affect stack &
local variables if we call from the main or
from an API that inturn calls AES in MontaVista.
main -> AES
main -> API_1 -> AES

2) But, if we have an AES invokation as below
in MontaVista, though it is working, it is
corrupting the stack & local variables and
hence the it is affecting other functionalities.
main -> API_1 -> API_2 ->AES

3) Without AES in MontaVista, i am able to goto
greater stack depths that are much greater than below.
main -> API_1 -> API_2 -> API_3 -> AIP_4

But, In RedHat, AES does not corrupt the stack for all
the above scenarios. Why does AES corrupt the Stack in
Fedora Core alone ? Any ideas ?

Correction - It should be Montavista
and hence It should be as below -
"Why does AES corrupt the Stack in
Montavista alone ? Any ideas ? "

 

[karthikbalaguru]

karthikbalaguru wrote:
Hi,
Consider that the below function returns the processed
output in pContent->load[6].
It should be pC->load[6] and it is not pContent->load[6].
checkfun(&ipdat, (unsigned char *)&pC->load[6]);
Either you're a careless typist, or you're using global
variables much too freely.
But, How is it possible that it works in Redhat Linux
and not in Montavista Linux ?
There are lots of possible reasons. Most likely is that there is some
bug in your program, and a difference in system software (kernel,
library or compiler versions or configuration) means that on one system
the bug happens not to cause a problem, but on the other one it does.
For instance, it could be that &pC->load[6] is pointing to some
incorrect address. On Montavista perhaps the memory where it points
actually contains some other data which is being changed at the same
time. On Redhat, it could be that due to a different memory layout the
memory where it points is something that isn't being changed, so you
don't see the corruption. But many other possibilities exist too.
I'd recommend debugging your code on the system where it breaks, since
that should make the bug easier to find. Once you know what is wrong,
you can examine with a debugger just what is occuring on the other
system, if you really want to know why it happens to work there. That
isn't very useful information though, although it could be fun.
If you can't find the bug, posting the source to a complete program
(stripped down if possible) that compiles and exhibits the problem would
let people on this newsgroup who are so inclined try to help you. I'll
warn you, though, that by posting to comp.lang.c, you will probably get a
lot of responses pointing out parts of your program that aren't legal or
result in "undefined behavior" according to the C language standard,
even though they may be perfectly legal on your particular Linux
systems, and have nothing to do with your problem. You may find
comp.os.linux.development.apps or comp.unix.programmer better in this
regard, though they also have a lower readership.
The important issue, though, is that you have not shown
us what pContent/pC points to: We don't know the type of the
`load' element, except that we can infer it must be either a
pointer or an array, but to what type? And is there any
reason to believe that the [6] element exists? And just how
does checkfun() produce "processed output?"
It is an algorithm that we use for getting the processed output
and hence did not refer to it.
But, Are there any specific set of C code that
will work in Redhat linux and not in Montavista Linux.
Possibly. It isn't likely that you're encountering them, so I'm not
going to blindly list possibilities. More likely you have some bug that
is wrong on both systems but by sheer luck doesn't fail on one of them.

The above was a code snippet(modified)
to define the problem in few lines.

Actually, I am working with AES algorithm.
I got AES CTR code(RFC 3686) from the below link -http://fp.gladman.plus.com/AES/index.htm.
I use C language.

On Analysis, i find that in Montavista
1) AES works well and does not affect stack &
local variables if we call from the main or
from an API that inturn calls AES in MontaVista.
main -> AES
main -> API_1 -> AES

2) But, if we have an AES invokation as below
in MontaVista, though it is working, it is
corrupting the stack & local variables and
hence the it is affecting other functionalities.
main -> API_1 -> API_2 ->AES

3) Without AES in MontaVista, i am able to goto
greater stack depths that are much greater than below.
main -> API_1 -> API_2 -> API_3 -> AIP_4

But, In RedHat, AES does not corrupt the stack for all
the above scenarios. Why does AES corrupt the Stack in
Fedora Core alone ? Any ideas ?

Correction - It should be Montavista
and hence It should be as below -
"Why does AES corrupt the Stack in
Montavista alone ? Any ideas ? "

On Analysis, I find that
the problem is related with AES algorithm.
If i comment the AES algorithm invokation,
i do not get any value/buffer corruption.
So, AES was isolated and tested before
integration for further analysis.
On further analysis w.r.t AES invokation,
i find the below w.r.t Montavista :-
1) AES works well and does not affect stack &
local variables if we call from the main or
from an API that inturn calls AES in MontaVista.
main -> AES
main -> API_1 -> AES

2) But, if we have an AES invokation as below
in MontaVista, though it is working, it is
corrupting the stack & local variables and
hence the it is affecting other functionalities.
main -> API_1 -> API_2 ->AES

3) Without AES in MontaVista, i am able to goto
greater stack depths that are much greater than below.
main -> API_1 -> API_2 -> API_3 -> AIP_4

Interestingly, In RedHat, AES does not corrupt the
stack for all the above scenarios.
But, Why does AES corrupt the Stack in Montavista
alone which inturn affects the buffer/variables ?
Any ideas ?

Thx in advans,
Karthik Balaguru

 

[Ben Bacarisse]

Actually, I am working with AES algorithm.
I got AES CTR code(RFC 3686) from the below link -
http://fp.gladman.plus.com/AES/index.htm.
I use C language.

On Analysis, i find that in Montavista
1) AES works well and does not affect stack &
local variables if we call from the main or
from an API that inturn calls AES in MontaVista.
main -> AES
main -> API_1 -> AES

2) But, if we have an AES invokation as below
in MontaVista, though it is working, it is
corrupting the stack & local variables and
hence the it is affecting other functionalities.
main -> API_1 -> API_2 ->AES

3) Without AES in MontaVista, i am able to goto
greater stack depths that are much greater than below.
main -> API_1 -> API_2 -> API_3 -> AIP_4

But, In RedHat, AES does not corrupt the stack for all
the above scenarios. Why does AES corrupt the Stack in
Fedora Core alone ? Any ideas ?

Well, for one thing, I think it is unlikely that the system has
anything to do with it other than revealing the problem via different
symptoms. Secondly, I don't understand what you mean by the examples
above. Third, your best chance of getting help is to post the
smallest piece of code that exhibits a problem (you can omit the AES
code -- anyone who needs to can pick that up from your link). Just
preparing such an example to post might be enough to reveal the issue.