gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] 2.6.2, random-tester progress


From: Mike Thomas
Subject: RE: [Gcl-devel] 2.6.2, random-tester progress
Date: Mon, 22 Mar 2004 12:06:36 +1000

Hi there.

Camm:

| > Gentlemen, all these appear to point to a setjmp/longjmp failure on
| > mingw, or at least gcl's use of such.  These can be heavily used by
| > the compiler at times, and its a bit embarrassing to ship such a
| > fragile situation.  We are sure to receive error reports about it for
| > some time, and it pretty much ensures that there must be a 2.6.3
| > later.  I will defer to the judgment of you three as you know the
| > windows situation far better than I -- we can either release what we
| > have, or fix this now if possible.  It should be a single fix as far
| > as I can tell.
| >
| > As far as I can tell there are no issues on Linux, FreeBSD, MacOSX,
| > and Solaris.
| >
| > If the three of you vote for 'release now', then Mike, please let me
| > know when your final installer bits are checked in and I'll make the
| > non-branch tag.  I've checked the memory management at the end of
| > maxpages, and it works correctly as far as I can see.  One needs
| > '256*1024' maxpages to run Paul's tester with 10,000/8.  At this size,
| > my test has been running now for > 24 hours, and I feel we have a good
| > shot at reaching the clisp 'bogey' of ~ 45k tests.  Am curious to know
| > how much memory clisp needs to compile these forms for this long.
| >
| > Take care,
| >

Vadim:

| If you think that all these Windows problems probably due
| to the same error then we can try to fix it.
| I'm inclined to believe your intuition.  The only bad thing about me
| personally is what with high probability I'll be able to do any
| debugging only to the end of coming week - maybe next weekend.

Much as I hate to keep on working on 2.6.1 at present due to work/time
pressure I do agree with Camm that we may well end up being plagued with a
2.6.3 unless we can sort it out.  As Vadim does, I trust Camm's analysis and
I'm looking further into it as and when I can.

What worries me Camm is that this will turn into another "ANSI build" bug.

I know very little about the semantics of ste/longjmp on Unix vs Windows but
in case someone can spot a difference I've included the MSDN info below.

I tried the MSDN example mentioned below with MinGW32 gcc using our build
flags and various levels of optimisation and it all seems to work correctly.

Cheers

Mike Thomas.


Here is what MSDN says about longjmp and setjmp:



============SETJMP=================================

Run-Time Library Reference

setjmp
Saves the current state of the program.

int setjmp(
   jmp_buf env
);
Parameter
env
Variable in which environment is stored.
Return Value
Returns 0 after saving the stack environment. If setjmp returns as a result
of a longjmp call, it returns the value argument of longjmp, or if the value
argument of longjmp is 0, setjmp returns 1. There is no error return.

Remarks
The setjmp function saves a stack environment, which you can subsequently
restore using longjmp. When used together, setjmp and longjmp provide a way
to execute a nonlocal goto. They are typically used to pass execution
control to error-handling or recovery code in a previously called routine
without using the normal calling or return conventions.

A call to setjmp saves the current stack environment in env. A subsequent
call to longjmp restores the saved environment and returns control to the
point just after the corresponding setjmp call. All variables (except
register variables) accessible to the routine receiving control contain the
values they had when longjmp was called.

Note   setjmp and longjmp do not support C++ object semantics. In C++
programs, use the C++ exception-handling mechanism.
Requirements
Routine Required header Compatibility
setjmp <setjmp.h> ANSI, Win 98, Win Me, Win NT, Win 2000, Win XP

For additional compatibility information, see Compatibility in the
Introduction.

Libraries

All versions of the C run-time libraries.

Example
See the example for _fpreset.


============LONGJMP================================
Restores stack environment and execution locale.

void longjmp(
   jmp_buf env,
   int value
);
Parameters
env
Variable in which environment is stored.
value
Value to be returned to setjmp call.
Remarks
The longjmp function restores a stack environment and execution locale
previously saved in env by setjmp. setjmp and longjmp provide a way to
execute a nonlocal goto; they are typically used to pass execution control
to error-handling or recovery code in a previously called routine without
using the normal call and return conventions.

A call to setjmp causes the current stack environment to be saved in env. A
subsequent call to longjmp restores the saved environment and returns
control to the point immediately following the corresponding setjmp call.
Execution resumes as if value had just been returned by the setjmp call. The
values of all variables (except register variables) that are accessible to
the routine receiving control contain the values they had when longjmp was
called. The values of register variables are unpredictable. The value
returned by setjmp must be nonzero. If value is passed as 0, the value 1 is
substituted in the actual return.

Call longjmp before the function that called setjmp returns; otherwise the
results are unpredictable.

Observe the following restrictions when using longjmp:

Do not assume that the values of the register variables will remain the
same. The values of register variables in the routine calling setjmp may not
be restored to the proper values after longjmp is executed.
Do not use longjmp to transfer control out of an interrupt-handling routine
unless the interrupt is caused by a floating-point exception. In this case,
a program may return from an interrupt handler via longjmp if it first
reinitializes the floating-point math package by calling _fpreset.
Note   Be careful when using setjmp and longjmp in C++ programs. Because
these functions do not support C++ object semantics, it is safer to use the
C++ exception-handling mechanism.
Requirements
Routine Required header Compatibility
longjmp <setjmp.h> ANSI, Win 98, Win Me, Win NT, Win 2000, Win XP

For additional compatibility information, see Compatibility in the
Introduction.

Libraries

All versions of the C run-time libraries.

Example
See the example for _fpreset.

See Also
Process and Environment Control Routines | setjmp | Run-Time Routines and
.NET Framework Equivalents







reply via email to

[Prev in Thread] Current Thread [Next in Thread]