gcl-devel
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: Re: [Gcl-devel] Windows GCL: setjmp/longjmp
Date: 25 Mar 2004 13:41:11 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> | > (gdb) finish
> | > Run till exit from #0  0x0041f217 in eval (form=0x1135c1b0) at
> | eval.c:1037
> | > 0x0041f981 in fLeval (x0=0x1060fba0) at eval.c:1178
> | > 1178            eval(x0);
> |
> | Could you start single stepping here,
> 
> 
> There are two runs included below my signature.  The problems are, I think,
> occurring in Iinvoke_c_function_from_value_stack().
> 
> On the first run there is trouble using pp with a longjump error from
> MSVCRT - included in case it makes sense to you.
> 

Think this is just a normal failure due to your trying to print base
instead of e.g. base[0].

> On the second I am a bit more careful with pp and see that base[0] is set at
> line 294 to the erroneous value 0x6b83f0 as follows (I don't understand how
> you know it is a bad value, incidentally) :
> 

>From your other email, I may be mistaken.  If 0x6b83f0 happens to by
&Ct_body or &Cnil_body, then this is OK.  I'm now assuming this is the
case.  

> ========================================================
> 
> 
> and that by this stage base and vs_base have diverged widely despite being
> set at the start of the function to be equal (line 266):
> 

This is normal, I believe.  The function call pushed values to the
stack.


> 
> ========================================================
> (gdb) p vs_top - vs_base
> $16 = 1
> (gdb) p vs_top - base
> $17 = 37
> ========================================================
> 
> 
> I don't see in the source code how this divergence could have validly
> occurred.
> 
> Incidentally, at the time of the break at mark_c_stack it looks as though
> the stack is already in trouble:
> 

Just a caution here -- gdb might not be able to report the stack trace
in all cases when functions are called from compiled lisp objects.


>From your first note:

=============================================================================
Test CL-VARIABLE-SYMBOLS.1 failed
Form: (LOOP
        FOR
        S
        IN
        *CL-VARIABLE-SYMBOLS*
        WHEN
        (NOT (BOUNDP S))
        COLLECT
        S)
Expected value: NIL
Actual value: (*COMPILE-FILE-PATHNAME* *COMPILE-FILE-TRUENAME*
                  *LOAD-PATHNAME* *LOAD-PRINT* *LOAD-TRUENAME*
                  *PRINT-LINES* *PRINT-MISER-WIDTH*
                  *PRINT-PPRINT-DISPATCH* *PRINT-RIGHT-MARGIN*
                  *READ-EVAL*).
 CL-TYPES-THAT-ARE-CLASSES.1 CL-TYPES-THAT-ARE-CLASSES.20x0041f217 in eval
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This test fails for me and should print error output like the above.
This is likely the first longjmp failure.  Can you set a break at
unwind when doing the cl-variables.1 test, step through the longjmp
into the clcs error code to see what should be happening, and then see
what differs when processing cl-types-that-are-classes.1?

...
(gdb) finish
Run till exit from #0  0x0044ae21 in Iinvoke_c_function_from_value_stack (
    f=0x41f925 <fLeval>, fargd=513) at nfunlink.c:293
0x0041f920 in Leval () at eval.c:1171
1171           ,1,1,NONE,OO,OO,OO,OO,void,Leval,(object x0),"")
(gdb) finish
Run till exit from #0  0x0041f920 in Leval () at eval.c:1171
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x104eb092: Input/output error.

Perhaps you could single step from this point and see what is trying
to access address 0x104eb092.  Is this past core_end?  What about
heap_end?



(gdb) p cs_org
$25 = (int *) 0x22ff88
(gdb) p cs_limit
$26 = (int *) 0x21c708
(gdb) p *cs_org
$27 = 1
(gdb) p *cs_limit
$28 = 269647600
(gdb) info registers
eax            0x6c1560 7083360
ecx            0x77c37856       2009299030
edx            0x6c1560 7083360
ebx            0x6c1560 7083360
esp            0x22e850 0x22e850
ebp            0x22e868 0x22e868
esi            0x6c1530 7083312
edi            0x6c156c 7083372
eip            0x41f920 0x41f920
eflags         0x246    582
cs             0x1b     27
ss             0x23     35
ds             0x23     35
es             0x23     35
fs             0x38     56
gs             0x0      0
(gdb)

This all looks fine.  Just a note -- cs_org-cs_limit is much smaller
on your machine, as it avoids the rlim code in main.c specific to the
bsd's.  I don't think this is a problem unless you get the message in
segmentation_catcher, which you don't.

(gdb) bt
#0  0x0041f920 in Leval () at eval.c:1171
#1  0x104eb092 in ?? ()
    ^^^^^^^^^^

Is this problem address that of a valid compiled function?

#2  0x00000001 in ?? ()
#3  0x1135c57c in ?? ()

I'm still a bit puzzled why you cannot continue here.

I also think it may be easier to debug the case where you get "The GO
tag NIL is not established."  Perhaps we can setup a parallel round
with that one.  Please remind me of the triggering command.

Take care,


> 
> 
> And so I bid you farewell for another day.
> 
> Cheers
> 
> Mike homas.
> 
> 
> 
> 
> 
> ==============================================================
> Run till exit from #0  0x0041f217 in eval (form=0x1135c1b0) at eval.c:1037
> 0x0041f981 in fLeval (x0=0x1060fba0) at eval.c:1178
> 1178            eval(x0);
> (gdb) p pp(x0)
> (SIGNALS-ERROR (SYMBOL-FUNCTION)
>                                 PROGRAM-ERROR)$43 = void
> 
> (gdb) watch vs_base[0]
> Hardware watchpoint 2: vs_base[0]
> (gdb) n
> 1179            lex_env = lex;
> (gdb) n
> 1180            return Ivs_values();
> (gdb) n
> 1181    }
> (gdb) n
> c_apply_n (fn=0x41f925 <fLeval>, n=1, x=0x22e730) at funlink.c:685
> 685      return res;
> (gdb) n
> 686     }
> (gdb) n
> Iinvoke_c_function_from_value_stack (f=0x41f925 <fLeval>, fargd=513)
>     at nfunlink.c:294
> 294       res = COERCE_F_TYPE(res,F_RESULT_TYPE(fargd),F_object);
> (gdb) s
> 295       base[0]=res;
> (gdb) p pp(res)
> T$44 = void
> (gdb) n
> 296       if (F_ARG_FLAGS_P(fargd,F_caller_sets_one_val))
> (gdb) p base
> $45 = (object *) 0x6c1560
> (gdb) n
> 300         { vs_top=base + fcall.nvalues;
> (gdb) p base
> $46 = (object *) 0x6c1560
> (gdb) p pp(base)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77c337c9 in msvcrt!_abnormal_termination ()
>    from C:\WINDOWS\system32\msvcrt.dll
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on"
> Evaluation of the expression containing the function (pp) will be abandoned.
> (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)
> ==============================================================
> 
> 
> 
> And start again:
> 
> 
> 
> ==============================================================
> (gdb) finish
> Run till exit from #0  0x0041f217 in eval (form=0x1135c1b0) at eval.c:1037
> 0x0041f981 in fLeval (x0=0x1060fba0) at eval.c:1178
> 1178            eval(x0);
> (gdb) p pp(x0)
> (SIGNALS-ERROR (SYMBOL-FUNCTION)
>                                 PROGRAM-ERROR)$6 = void
> (gdb) bt
> #0  0x0041f981 in fLeval (x0=0x1060fba0) at eval.c:1178
> #1  0x00431dc6 in c_apply_n (fn=0x41f925 <fLeval>, n=1, x=0x22e730)
>     at funlink.c:363
> #2  0x0044ae21 in Iinvoke_c_function_from_value_stack (f=0x41f925 <fLeval>,
>     fargd=513) at nfunlink.c:293
> #3  0x0041f920 in Leval () at eval.c:1171
> #4  0x104eb092 in ?? ()
> #5  0x00000001 in ?? ()
> #6  0x1135c57c in ?? ()
> (gdb) watch vs_base[0]
> Hardware watchpoint 2: vs_base[0]
> (gdb) bt
> #0  0x0041f981 in fLeval (x0=0x1060fba0) at eval.c:1178
> #1  0x00431dc6 in c_apply_n (fn=0x41f925 <fLeval>, n=1, x=0x22e730)
>     at funlink.c:363
> #2  0x0044ae21 in Iinvoke_c_function_from_value_stack (f=0x41f925 <fLeval>,
>     fargd=513) at nfunlink.c:293
> #3  0x0041f920 in Leval () at eval.c:1171
> #4  0x104eb092 in ?? ()
> #5  0x00000001 in ?? ()
> #6  0x1135c57c in ?? ()
> (gdb) n
> 1179            lex_env = lex;
> (gdb) n
> 1180            return Ivs_values();
> (gdb) n
> 1181    }
> (gdb) n
> c_apply_n (fn=0x41f925 <fLeval>, n=1, x=0x22e730) at funlink.c:685
> 685      return res;
> (gdb) n
> 686     }
> (gdb) n
> Iinvoke_c_function_from_value_stack (f=0x41f925 <fLeval>, fargd=513)
>     at nfunlink.c:294
> 294       res = COERCE_F_TYPE(res,F_RESULT_TYPE(fargd),F_object);
> (gdb) n
> 295       base[0]=res;
> (gdb) n
> 296       if (F_ARG_FLAGS_P(fargd,F_caller_sets_one_val))
> (gdb) p pp(res)
> T$7 = void
> (gdb) s
> 300         { vs_top=base + fcall.nvalues;
> (gdb) p base
> $8 = (object *) 0x6c1560
> (gdb) p vs_base
> $9 = (object *) 0x6c15f0
> (gdb) p vs_base[0]
> $10 = 0x6b83f0
> (gdb) p base[0]
> $11 = 0x6b83f0
> (gdb) p fcall.nvalues
> $12 = 1
> (gdb) p vs_top
> $13 = (object *) 0x6c15f4
> (gdb) p nargs
> $14 = 1
> (gdb) p i
> $15 = 1
> (gdb) p vs_top - vs_base
> $16 = 1
> (gdb) p vs_top - base
> $17 = 37
> (gdb) p next
> No symbol "next" in current context.
> (gdb) n
> 301           { int nn = fcall.nvalues;
> (gdb) n
> 302             while (--nn > 0)
> (gdb) n
> 307       vs_base=base;
> (gdb) p base
> $18 = (object *) 0x6c1560
> (gdb) p vs_base
> $19 = (object *) 0x6c15f0
> (gdb) n
> 309     }
> (gdb) n
> 0x0041f920 in Leval () at eval.c:1171
> 1171           ,1,1,NONE,OO,OO,OO,OO,void,Leval,(object x0),"")
> (gdb) bt
> #0  0x0041f920 in Leval () at eval.c:1171
> #1  0x104eb092 in ?? ()
> #2  0x00000001 in ?? ()
> #3  0x1135c57c in ?? ()
> (gdb) n
> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0x1: Input/output error.
> 
> (gdb)
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  because...
> |
> | > (gdb) finish
> | > Run till exit from #0  0x0041f981 in fLeval (x0=0x1060fba0) at
> | eval.c:1178
> | > 0x00431dc6 in c_apply_n (fn=0x41f925 <fLeval>, n=1, x=0x22e730)
> | >     at funlink.c:363
> | > 363         case 1:  res=LCAST(fn)(x[0]);break;
> | > Value returned is $23 = 0x6b83f0
> |                           ^^^^^^^^
> |
> | this is not a valid object pointer.  Perhaps pp(x0) above.
> 
> | Something
> | truncated the top byte when writings to vs_base[0].  Can you
> | investigate?
> |
> | Take care,
> |
> |
> | --
> | Camm Maguire                                                address@hidden
> | ==========================================================================
> | "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> |
> |
> | _______________________________________________
> | 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




reply via email to

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