Address of a variable on Stack Changes ..
Ripunjay Tripathi
I compiled and executed simple C program as below -
int main()
{
int cpid = 0;
int var = 10;
cpid = fork();
if(cpid) //parent
{
sleep(10); // just to ensure child finishes first
}
else //child
{
var = 20;
}
printf("\n var = %d, pid = %d \n", var, getpid());
return 0;
}
This program was executed on two different versions of linux.
Redhat 8 and
Enterprise Linux v9 with probably two different versions of gcc (I
forgot the versions. Sorry !!)
On execution things appeared as expected. The values for "var" were
different in child and parent processes.
But there was a remarkable difference -
In Redhat 8 the address for "var" in different executions of the same
compiled executable was same however it was different in different
executions in Enterprise Linux 9.
The catch is probably we have different implementations of "Stack" in
two different systems of glibc. Need your help in understanding this.
Surprisingly the address for "var" in any given execution was same in
both of parent and child processes.
The similar behaviour was observed in AIX system with XLC compiler. In
Windows operating system however the address was same in different
executions as in Redhat 8.
-----
Ripunjay Tripathi
Ripunjay Tripathi
wrote:
Plz excuse me if the my post above is an ODD one in this group.
Francis Glassborow
> Guys,
>
> I compiled and executed simple C program as below -
>
> int main()
> {
> int cpid = 0;
> int var = 10;
>
> cpid = fork();
code. That means anything could happen. You need to look at the
documentation for your compiler to determine what is being done.
Kaz Kylheku
> Guys,
>
> I compiled and executed simple C program as below -
>
> int main()
> {
> int cpid = 0;
> int var = 10;
>
> cpid = fork();
Since you didn't define this fork function in your program, and it's not
in standard C, your program invokes undefined behavior.
For instance, its translation and linkage may terminate with a
diagnostic message like ``unresolved symbol: fork''.
> But there was a remarkable difference -
> In Redhat 8 the address for "var" in different executions of the same
> compiled executable was same however it was different in different
> executions in Enterprise Linux 9.
You have the address space randomization enabled in the kernel.
http://en.wikipedia.org/wiki/Address_space_layout_randomization
The C language standard doesn't require the addresses of similar
objects in different executions of a program to be the same.
It is only due to an amazing amount of complexity in the CPU and
operating system that a multi-tasking OS /can/ give every program
the same addresses of executable code, static variables and stack.
Without virtual memory providing separate address spaces, this would be
impossible; every task would have to have different addresses for all of
its data and code areas.
Geoff
This is a function of the operating system. Under OS X 10.4.11 your
program produces the same address for each fork consistently for each
execution of the program and from run to run. The address is different
when debugged in GDB but the address is invariant from run to run and
between each fork whether or not the debugger is active. Under FC8 the
address is different from run to run but invariant between forks.
I suspect your EL9 system has address space layout randomization
(ASLR) turned on where your RH8 doesn't. Windows XP doesn't use ASLR
by default, it wasn't introduced until Vista.
Dag-Erling Smørgrav
> int main()
Incorrect prototype, and at least three missing #includes.
> cpid = fork();
> if(cpid) //parent
"parent or failed", to be precise.
> {
> sleep(10); // just to ensure child finishes first
> }
Setting aside the usual complaints about fork() (which has nothing to do
with multi-threading, Francis) being off-topic to c.s.c: that is not a
valid assumption. It will *probably* work as you intended *in most
cases*, but there is no guarantee. There are several solutions to this
problem (POSIX semaphores, SysV semaphores, pipes / socket pairs etc.),
but the simplest is to have the parent call waitpid(), which (with the
right arguments) will block until the child terminates.
> In Redhat 8 the address for "var" in different executions of the same
> compiled executable was same however it was different in different
> executions in Enterprise Linux 9.
There is nothing in your program that will allow you to determine "the
address for var", so clearly the program you posted is not the one you
actually ran. That's a big no-no.
> The catch is probably we have different implementations of "Stack" in
> two different systems of glibc. Need your help in understanding this.
The execution stack is not implemented in the library.
DES
--
Dag-Erling Smørgrav - d...@des.no