Re: [Gcl-devel] Windows GCL: setjmp/longjmp

[Camm Maguire]

OK, my next guess is that we've run out of C stack space.  setjmp
pushes the environment to the C stack.  And these bugs seem to show up
only after several good iterations.  We need to trap the error in gdb,
and look at the esp register, cs_org, and cs_limit.  Ideally, we can
trap right before the error and look at the address of a local C
variable too.  Perhaps mark_c_stack would be good, with the proper
number of ignores, which can be determined by running with (setq
si::*notify-gbc*) first, and either counting the gc's by hand, or
looking at (room) at the error point.

Take care,

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> With a -fvolatile build on the stable branch there is no difference.
> 
> Catching the ANSI test crash with the debugger gives the same corrupted
> stack problem I mentioned when we first tried to catch this one.
> 
> ===============================================
> Test SPECIAL-OPERATOR-P.1 failed
> Form: (LOOP
>         FOR
>         S
>         IN
>         +SPECIAL-OPERATORS+
>         UNLESS
>         (SPECIAL-OPERATOR-P S)
>         COLLECT
>         S)
> Expected value: NIL
> Actual value: (LOAD-TIME-VALUE SYMBOL-MACROLET).
> Test SPECIAL-OPERATOR-P.2 failed
> Form: (LET ((P (FIND-PACKAGE "CL")))
>         (LOOP
>           FOR
>           NAME
>           IN
>           *CL-SYMBOL-NAMES*
>           UNLESS
>           (OR (MEMBER NAME +SPECIAL-OPERATORS+ :TEST #'STRING=)
>               (LET ((SYM (FIND-SYMBOL NAME P)))
>                 (OR (NOT (SPECIAL-OPERATOR-P SYM))
>                     (MACRO-FUNCTION SYM))))
>           COLLECT
>           NAME))
> Expected value: NIL
> Actual value: ("DECLARE").
>  SPECIAL-OPERATOR-P.ORDER.1
> Program received signal SIGSEGV, Segmentation fault.
> 0x77c337c9 in msvcrt!_abnormal_termination ()
>    from C:\WINDOWS\system32\msvcrt.dll
> (gdb) bt
> #0  0x77c337c9 in msvcrt!_abnormal_termination ()
>    from C:\WINDOWS\system32\msvcrt.dll
> #1  0x77c37856 in strerror () from C:\WINDOWS\system32\msvcrt.dll
> #2  0x77c34e9a in msvcrt!longjmp () from C:\WINDOWS\system32\msvcrt.dll
> (gdb)
> =================================================
> 
> I'll try and catch the HEAD build instead in the hope that the debugger
> stack report is more meaningful.
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> | -----Original Message-----
> | From: Camm Maguire [mailto:address@hidden
> | Sent: Monday, 22 March 2004 12:54 PM
> | To: Mike Thomas
> | Cc: Vadim V. Zhytnikov; Mike Thomas; GCL List;
> | address@hidden
> | Subject: Re: [Gcl-devel] Windows GCL: setjmp/longjmp
> |
> |
> | Greetings!  As a first pass, could someone please check both the two
> | ansi build failures and the maxima ignore-errors issue when the
> | underlying gcl has been built with --enable-debug?  It would also be
> | interesting in addition to add -fvolatile to all CFLAGS.  One should
> | be able to simply set the CFlAGS env variable before configure, and
> | find one's setting in all FLAGS variables in the makedefs.
> |
> | Take care,
> |
> | "Mike Thomas" <address@hidden> writes:
> |
> | > Hi all.
> | >
> | > Here is a question:
> | >
> | > | 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.
> | >
> | >
> | > My understanding is that any local variable is likely to be a register
> | > variable as most compilers these days ignore programmer usage of the
> | > register storage modifier.
> | >
> | > Is that true?
> | >
> | > If so, then format.c looks like a good place to start looking
> | for trouble
> | > with setjmp/longjmp.
> | >
> | > Unfortunately, so far I haven't been able to come up with a
> | format statement
> | > which causes a problem.
> | >
> | > Cheers
> | >
> | > Mike Thomas.
> | >
> | >
> | >
> | >
> | >
> | > _______________________________________________
> | > Gcl-devel mailing list
> | > address@hidden
> | > http://mail.gnu.org/mailman/listinfo/gcl-devel
> | >
> | >
> |
> | --
> | Camm Maguire                                                address@hidden
> | ==========================================================================
> | "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> |
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah