[Tcl-bugs] [ tcl-Patches-746378 ] experimental unix stack check patch...

[SourceForge.net <no...@so...>]

Patches item #746378, was opened at 2003-05-30 15:35
Message generated for change (Comment added) made by hobbs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=746378&group_id=10894

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Joe Mistachkin (mistachkin)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: experimental unix stack check patch...

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-10-12 16:35

Message:
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.

----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-06-02 13:44

Message:
Logged In: YES 
user_id=113501

Attached a simple test script.


----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-06-02 13:34

Message:
Logged In: YES 
user_id=113501

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


----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-05-31 21:24

Message:
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.


----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-05-30 18:40

Message:
Logged In: YES 
user_id=113501

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

Please test.


----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-05-30 16:34

Message:
Logged In: YES 
user_id=113501

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


----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2003-05-30 15:53

Message:
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].



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=746378&group_id=10894