Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, 3 Feb 2012, Juan Jose Garcia-Ripoll wrote:
I just noticed that some cleverly optimizing compilers broke the code I used
to detect whether the stack grows upwards or downwards. I will upload a patch
tonight.
Wouldn't two calls to alloca() in a single function give a reliable answer
on pretty much all platforms?
#include alloca.h
#include stdio.h
int main()
{
void *x;
void *y;
x=alloca(100);
y=alloca(100);
printf(delta: %d\n, (int)(y-x));
return 0;
}
The following was another idea; but it looks no better than what you have
now.
#include stdio.h
#include stdlib.h
void * start;
void * end;
void recurse(int n, void *y)
{
int x;
if(n==0)
end=x;
else
recurse(n-1, x);
}
int main(int argc, char **argv)
{
int x;
int times;
start=x;
times=(random()%10)+1;
recurse(times, start);
printf(delta: %d\n, (int)(end-start));
return 0;
}
This link indicates Sparc could violate some common assumptions about
stack behavior (though it looks to me like he was confusing the register
window with the stack).
http://stackoverflow.com/questions/664744/what-is-the-direction-of-stack-growth-in-most-modern-systems
- Daniel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Thu, Feb 9, 2012 at 8:24 PM, Daniel Herring dherr...@tentpost.com wrote:
On Fri, 3 Feb 2012, Juan Jose Garcia-Ripoll wrote:
I just noticed that some cleverly optimizing compilers broke the code I used
to detect whether the stack grows upwards or downwards. I will upload a
patch tonight.
Wouldn't two calls to alloca() in a single function give a reliable answer
on pretty much all platforms?
#include alloca.h
#include stdio.h
int main()
{
void *x;
void *y;
x=alloca(100);
y=alloca(100);
printf(delta: %d\n, (int)(y-x));
You probably want to cast x and y to intptr_t and compare instead of the
substraction: you can't subtract two pointers that are not related to the same
object. You also probably want to check for availability of alloca.
return 0;
}
The following was another idea; but it looks no better than what you have
now.
#include stdio.h
#include stdlib.h
void * start;
void * end;
void recurse(int n, void *y)
{
int x;
if(n==0)
end=x;
else
recurse(n-1, x);
}
int main(int argc, char **argv)
{
int x;
int times;
start=x;
times=(random()%10)+1;
recurse(times, start);
printf(delta: %d\n, (int)(end-start));
return 0;
}
This link indicates Sparc could violate some common assumptions about
stack behavior (though it looks to me like he was confusing the register
window with the stack).
http://stackoverflow.com/questions/664744/what-is-the-direction-of-stack-growth-in-most-modern-systems
- Daniel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote: I just noticed that some cleverly optimizing compilers broke the code I used to detect whether the stack grows upwards or downwards. I will upload a patch tonight. Hmm. The code in question invoked an undefined behaviour. So, it was just a disaster waiting to happen. The compilers can't be blamed. -- Gaby -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 4:45 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote: I just noticed that some cleverly optimizing compilers broke the code I used to detect whether the stack grows upwards or downwards. I will upload a patch tonight. Hmm. The code in question invoked an undefined behaviour. So, it was just a disaster waiting to happen. The compilers can't be blamed. I did not say imply that the C compilers are wrong. ECL is assuming that local variables are kept in the stack. Is this wrong? Perhaps, but this is an implicit assumption in all C garbage collectors I know and so far no compiler has broken this assumption. It is an undefined behavior as per the ANSI C specification, but that is not what broke the code ECL used. What broke the test is the fact that the functions from the test were inlined and thus the local variables ended up in a different order in the stack, not the original assumption. I have made the code non-deterministic so most compilers will not inline the calls and hopefully the growth test works. Finally, though the test is fragile, it is not critical. Stack growth direction is only used in two places 1* In ECL's code for detecting stack overflows. We might do without it, but graceful handling of stack overflows based on alternative stacks proved to be useless due to the signal-async problem. 2* In the Boehm-Weiser garbage collector to detect the extent of the stack on different threads. As I said, this is a common assumption across C implementations of garbage collectors and so far never broken. So all in all, the broken test only affected 1 and now it seems to work. Best, Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 10:13 AM, Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote: ECL is assuming that local variables are kept in the stack. Is this wrong? What is undefined behaviour isn't assuming the notion of stack -- which the C standard effectively does not know about. The crucial point is that it is undefined to compare the address of two distinct objects for relative position (e.g. before or after) unless they are part of an array (or one last the end address.) Perhaps, but this is an implicit assumption in all C garbage collectors I know and so far no compiler has broken this assumption. It is an undefined behavior as per the ANSI C specification, but that is not what broke the code ECL used. That wasn't it (thought it could have.) What broke the test is the fact that the functions from the test were inlined and thus the local variables ended up in a different order in the stack, not the original assumption. Exactly. Because the local variables were distinct objects. I have made the code non-deterministic so most compilers will not inline the calls and hopefully the growth test works. I hope you realize that it is just delaying the breakage point in time. Finally, though the test is fragile, it is not critical. Stack growth direction is only used in two places 1* In ECL's code for detecting stack overflows. We might do without it, but graceful handling of stack overflows based on alternative stacks proved to be useless due to the signal-async problem. 2* In the Boehm-Weiser garbage collector to detect the extent of the stack on different threads. As I said, this is a common assumption across C implementations of garbage collectors and so far never broken. This confusese two things: (1) the existence of a stack; (2) the direction of growth. The test for (2) is invoking an undefined behaviour. Therefore, the outcome of that test does not say anything about the collector's assumption that there is a stack (1) and a defined direction of growth. So all in all, the broken test only affected 1 and now it seems to work. Best, Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 5:24 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: This confusese two things: (1) the existence of a stack; (2) the direction of growth. The test for (2) is invoking an undefined behaviour. Therefore, the outcome of that test does not say anything about the collector's assumption that there is a stack (1) and a defined direction of growth. Actually, both things are related. The collector uses the same logic. It assumes that there is a stack (1) and it assumes that when GC is invoked, the address that it currently has (a) can be retrieved by looking at the closest atomic variable and (b) it can be compared with a similarly retrieved address found at the thread's entry point This is what I have always found in all the versions I have reviewed, except for some platforms that offer an API to retrieve that information from different threads. It is also the reason why the GC has some funny API, intercepting calls to pthread_create() and providing functions to import a current thread... So yes, I know that the assumption that automatic variables and call frames are sorted is based on a de-facto standard and could be broken, but right now there is no other way which does not involve nonportable assembly code and changing the GC library as well. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
