Re: [Gcl-devel] cvs build on linux aborts

[Camm Maguire]

Greetings!

robert read <address@hidden> writes:

> I built static raw_gcl and using gdb I found that I'm getting the error
> during the first  funcall after init_init() is called.  It looks like
> it occurs in one of the object files loaded, but which one I'm not
> sure.  The last source line I can trace to is eval.c:101, which in
> this case is set to call something called LI1 with zero arguments:
> 
>       98      for (j=0; j<n ; j++)
>       99        {enum ftype typ=SFUN_NEXT_TYPE(i);
>      100         x[j]=COERCE_ARG(vs_base[j],typ);}}
>      101   SET_TO_APPLY(res,(object (*)())fun->sfn.sfn_self,n,x);
>      102   base[0]=
>      103     (restype==f_object ?  res :
>      104      restype==f_fixnum ? make_fixnum((int)res)
> 
> Here is a stack trace:
> 0x080acb45 in LI1 ()
> (gdb)
> Single stepping until exit from function LI1,
> which has no line number information.
> 

OK, once you get a working gcl, you might want to look at the C code
it produces when compiling a lisp file.  Not very pretty!  I can post
for your obfuscatory pleasure if desired :-).  In general, when
loading objects and then calling the functions they define, the
existing tracing information is obliterated.  Its roughly analogous to
debugging code with setlongjmp, and this may actually be the case
we're looking at here.  What I do is set a break at do_init, which
every object file calls on load.  Then I can trace a bit further.  

I'm a little confused at your observation that a segfault is
happening.  Set breakpoints at error and segmentation_catcher.  The
latter is where you should be, but the output indicates you are in the
former.  You can then do a backtrace from there.  You should also see
the signal in gdb, and be able to deal with it (via 'handle') there
first.  The fact that you did not suggests to me that you may not be
getting a signal, but that you may be jumping to a bad function
address which lands you in error().  But you saw it on the strace.
Hmmm. 

I always use libefence for memory/segmentation debugging, but it has
yet to help me here, most likely due to the unusual memory
management/garbage collection setup which might not rely on malloc
very heavily.

Take care,  

> >
> Error: Caught fatal error [memory may be damaged]
> Error signalled by an anonymous function.
> 
> Breakpoint 2, quick_call_sfun (fun=0x821a1e0) at eval.c:101
> 101       SET_TO_APPLY(res,(object (*)())fun->sfn.sfn_self,n,x);
> (gdb) bt
> #0  quick_call_sfun (fun=0x821a1e0) at eval.c:101
> #1  0x08051222 in funcall (fun=0x821a1e0) at eval.c:164
> #2  0x08096225 in call_or_link (sym=0x822ac84, link=0x81ae3d4) at
> funlink.c:29
> #3  0x080b3779 in LnkT161 ()
> #4  0x080adb3b in L4 ()
> #5  0x080511e4 in funcall (fun=0x82271a0) at eval.c:159
> #6  0x08096225 in call_or_link (sym=0x82305a0, link=0x81ae3c0) at
> funlink.c:29
> #7  0x080b36d9 in LnkT168 ()
> #8  0x080aebc2 in LI6 ()
> #9  0x0805107b in call_vfun (fun=0x821a028) at eval.c:134
> #10 0x08051259 in funcall (fun=0x821d0fc) at eval.c:169
> #11 0x0809b682 in IapplyVector (fun=0x821d0fc, nargs=5,
> base=0xbfffd000) at nfunlink.c:245
> #12 0x0809caa8 in Iapply_fun_n (fun=0x821d0fc, n=5, m=0,
> __builtin_va_alist=136436580) at utils.c:107
> #13 0x08093887 in fLerror (fmt_string=0x8241f30,
> __builtin_va_alist=-1073753684) at error.c:154
> #14 0x08093990 in FEerror (s=0x81a44c0 "Caught fatal error [memory may
> be damaged]", num=0, arg1=0xbfffd1ac, arg2=0x80486be,
>     arg3=0x821868c, arg4=0x8216f70) at error.c:196
> #15 0x080486cd in error (s=0x81a4773 "can't reset cs_limit") at
> main.c:340
> #16 0x08048fd1 in siLreset_stack_limits (arg=0) at main.c:677
> #17 0x080acd84 in LI1 ()
> #18 0x08050c7a in quick_call_sfun (fun=0x821a050) at eval.c:101
> #19 0x08051222 in funcall (fun=0x821a050) at eval.c:164
> #20 0x08052339 in super_funcall (fun=0x8219dec) at eval.c:748
> #21 0x0804864e in main (argc=1, argv=0xbffff2a4, envp=0xbffff2ac) at
> main.c:313
> #22 0x08140b64 in __libc_start_main (main=0x80481e0 <main>, argc=1,
> ubp_av=0xbffff2a4, init=0x80480b4 <_init>,
>     fini=0x818ad60 <_fini>, rtld_fini=0, stack_end=0xbffff29c) at
>     ../sysdeps/generic/libc-start.c:129
> (gdb)
> 
> Although the segfault doesn't show here, probably becase it is caught
> by the catcher, I saw the segfault happen with strace. Hope this is of
> some help.
> 
> robert
> 
> 
> 
> _______________________________________________
> 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