Tcl Source Code

This patch has been tested on Linux, FreeBSD, and 
Solaris.

This is a VERY experimental patch.  

Please test this on your Unix platform of choice.

File Deleted - 91518: 



File Added - 91568: unixStackCheck.v6.diff

Logged In: YES 
user_id=79902

Here's a version that I applied to the HEAD and which
appears clean and effective under Linux. Further development
now belongs to the bug tracker!

File Added - 91518: unixStackCheck.v5.diff

Logged In: YES 
user_id=79902

Try this version which:
 a) Applies to the current HEAD :^)
 b) Refactors the code to reduce the amount of #ifdef
hackery and conditional code; it is easier for one person to
maintain both branches of the code now...

(Appears to work non-threaded on Linux...)

Logged In: YES 
user_id=148712

Haven't looked at this in a while. I recall thinking that,
as this function is called very often, it might be better to
check the stack-growth direction at compile time to avoid
branching at run time - premature optimisation?

Logged In: YES 
user_id=113501

This patch doesn't modify the configure script or any of the 
test cases. After reviewing your patch, I would say we should 
probably combine the approach taken by my patch with the 
modularity of your patch (such as the 
TclpInitCheckStackSpace function and compile-time detection 
of whether the stack grows up or down, or do we prefer the 
runtime detection?).

Logged In: YES 
user_id=148712

Joe: please confirm or correct my remark in patch 450795 -
namely, that this patch completely supercedes that one

Logged In: YES 
user_id=72656

This can be added to the HEAD after the following changes:
It needs to not compile in by default - it currently does.
The super debug printfs should be handled like the TRACE 
functions in generic/tclExecute.c - with a macro at the top 
that defaults to nothing.  That will clean up the code a lot.

File Added - 51967: stack.tcl

Logged In: YES 
user_id=113501

Attached a simple test script.

File Added - 51966: unixStackCheckV4.zip

Logged In: YES 
user_id=113501

This has now been tested with 8.4.x.
Added casting corrections provided by jenglish.

File Added - 51837: unixStackCheckV3.zip

Logged In: YES 
user_id=113501

Been working on this patch to fine tune it a bit more.

The defines still need to be made more portable by 
using configure.

In my opinion, here is how it should work:

On FreeBSD with threads enabled, the pthread library 
function pthread_attr_get_np function should be used 
to check the maximum stack size for each thread.  The 
reason for this is that getrlimit for RLIMIT_STACK is 
horribly broken when pthreads are used.

On FreeBSD with threads disabled, the getrlimit function 
should be used to check the maximum stack size.

So far, on all other tested operating systems (Linux, 
Solaris, OpenBSD) it looks like the getrlimit function 
should be used, regardless of whether or not threads are 
enabled.

On Linux, there is a function that is could be a good 
candidate for checking the maximum stack size, 
pthread_getattr_np.  However, it does not seem to 
report the correct stack size (at least on the version of 
Linux I tested on), making it worse than useless.

Please note that this patch is thread safe whether or not 
it uses pthreads to get the stack size.

I am unsure about NetBSD and other platforms not 
mentioned here.

It would also be nice if there was a way to explicitly 
specify the stack checking behavior from configure, 
such as --disable-stack-check (old way) and --enable-
stack-check (new way), etc.

File Added - 51787: unixStackCheckV2.zip

Logged In: YES 
user_id=113501

New thread-safe version of the previous patch, various 
other clean up done.

Please test.

Logged In: YES 
user_id=113501

OpenBSD 3.2: OK.
RedHat 7.3 (it wasn't 9.0): OK.

Logged In: YES 
user_id=113501

FreeBSD 4.8-STABLE: OK.
SuSE 8.0 Linux: OK.
Solaris 8: OK.
RedHat 9.0 (?) Linux: OK.

This patch will work when compiling with threads 
enabled, however, it is not thread safe [yet].

File Added - 51776: unixStackCheck.zip