[Top][All Lists]
[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
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, (continued)
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, Camm Maguire, 2004/03/21
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/21
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/22
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, Camm Maguire, 2004/03/23
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/23
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, Camm Maguire, 2004/03/23
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/23
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, Camm Maguire, 2004/03/24
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/24
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/25
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp,
Camm Maguire <=
- Re: [Gcl-devel] Windows GCL: setjmp/longjmp, Camm Maguire, 2004/03/21
- RE: [Gcl-devel] Windows GCL: setjmp/longjmp, Mike Thomas, 2004/03/21
- Re: [Gcl-devel] Re: GCL produces wrong EOL on mingw, Camm Maguire, 2004/03/20
- Re: [Gcl-devel] Re: GCL produces wrong EOL on mingw, Mike Thomas, 2004/03/21
- Re: [Gcl-devel] Re: GCL produces wrong EOL on mingw, Vadim V. Zhytnikov, 2004/03/21
- RE: [Gcl-devel] Re: GCL produces wrong EOL on mingw, Mike Thomas, 2004/03/21
- Re: [Gcl-devel] Re: GCL produces wrong EOL on mingw, Mike Thomas, 2004/03/21