gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: GCL and valgrind


From: Camm Maguire
Subject: [Gcl-devel] Re: GCL and valgrind
Date: 07 Dec 2004 09:36:40 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Hi Tim!  And thank you so much for the introduction to valgrind!

The code indicated is in the garbage collector.  You can trigger the
same running ordinary gcl under valgrind by invoking (gbc t).  When
gcl is built with debugging, source line numbers are also printed, and
when valgrind is run with --db-attach=yes, one can step into the
debugger at the point in question.  Very useful.

Unfortunately, I'm not really sure what can be done about this.  GCL's
garbage collection algorithm is 'conservative', at least with respect
to the C stack.  What this means is that the C stack is walked looking
for potential lisp objects, which are marked when found.  The origin
of this walk is the address of the argc argument to main() -- the
endpoint is the address of a dummy local variable in the top stack
frame (i.e. that of the current function).  Normally, the assembler
code output by gcc fills in the stack continuously by pushing normal
word-sized arguments with each function call.  Apparently situations
can also arise where the stack pointer is incremented by a larger
amount in one step, presumably to achieve certain alignment, leaving
an uninitialized 'hole' in the active stack region.  These situations
appear to be quite rare (given the size of the stack traversed in this
algorithm).  

I'm still looking into this to see if I can recognize where and why
the stack is differently initialized at these points.  But broadly
speaking, the 'conservative' algorithm makes no assumptions about the
contents of the stack at all, and takes the cautious point of view
that if there is anything that looks like an object pointer that could
be stored in a local variable in any frame above the present one, that
it should be marked regardless of whether this is an accidental
situation or not.  More specifically, there is no way (that I know of
at least) to distinguish between initialized stack and 'holes', nor is
there any way within C to ensure that the stack is contiguous.  One
might attempt something very ugly and quite unworkable, to store the
last address of the caller which would be compared with the first
address of the callee at every function call, doing a memset if there
was a gap.  Needless to say this is fraught with peril an highly
unportable.  There might be some gcc/gas switches which could help
too.  Its worth looking at for a bit.  But I just wanted to say that
these messages do not point to an error in the implementation of the
algorithm.  This is the way the algorithm is supposed to work,
processing possibly random uninitialized junk, but marking any object in
the heap possibly pointed to just to be safe.

Take care,

Tim Daly  <address@hidden> writes:

> Camm,
> 
> I ran GCL under valgrind and found no errors.
> I then ran interpsys under valgrind and get:
> 
> =================================================================
> bash-2.05b# valgrind --tool=memcheck ./interpsys
> ==9634== Memcheck, a memory error detector for x86-linux.
> ==9634== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
> ==9634== Using valgrind-2.2.0, a program supervision framework for x86-linux.
> ==9634== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==9634== For more details, rerun with: -v
> ==9634== 
> ==9634== Syscall param sigaction(act) contains uninitialised or unaddressable 
> byte(s)
> ==9634==    at 0x1BA0144F: __GI___libc_sigaction (in /lib/libc-2.3.2.so)
> ==9634==    by 0x1BA01539: sigaction (in /lib/libc-2.3.2.so)
> ==9634==    by 0x81B23F2: bsdSignal (in /home/axiom/obj/linux/bin/interpsys)
> ==9634==    by 0x804C801: open_server (in /home/axiom/obj/linux/bin/interpsys)
> ==9634==  Address 0x52BFDF7C is on thread 1's stack
>                         AXIOM Computer Algebra System 
>              Version of Thursday November 18, 2004 at 21:11:34 
> -----------------------------------------------------------------------------
>    Issue )copyright to view copyright notices.
>    Issue )summary for a summary of useful system commands.
>    Issue )quit to leave AXIOM and return to shell.
> -----------------------------------------------------------------------------
>  
>    Re-reading compress.daase   Re-reading interp.daase
>    Re-reading operation.daase
>    Re-reading category.daase
>    Re-reading browse.daase==9634== 
> ==9634== Conditional jump or move depends on uninitialised value(s)
> ==9634==    at 0x805E438: mark_stack_carefully (in 
> /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Conditional jump or move depends on uninitialised value(s)
> ==9634==    at 0x805E444: mark_stack_carefully (in 
> /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E453: mark_stack_carefully (in 
> /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Conditional jump or move depends on uninitialised value(s)
> ==9634==    at 0x805E4B6: mark_stack_carefully (in 
> /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E4B8: mark_stack_carefully (in 
> /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Conditional jump or move depends on uninitialised value(s)
> ==9634==    at 0x805DB95: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DB97: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DB9D: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DBA3: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DFB8: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DFCE: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DF61: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DB24: mark_cons (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DB36: mark_cons (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E340: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E347: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E36E: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E008: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805E01E: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DDF6: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DEC8: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DED4: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DEEF: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> ==9634== 
> ==9634== Use of uninitialised value of size 4
> ==9634==    at 0x805DF08: mark_object (in /home/axiom/obj/linux/bin/interpsys)
> 
> 
> "running /root/.axiom.input"
> Value = NIL
> Value = NIL
> (1) -> 1
> 
>    (1)  1
>                                                         Type: PositiveInteger
> (2) -> )quit
> ==9634== 
> ==9634== ERROR SUMMARY: 4508 errors from 25 contexts (suppressed: 21 from 1)
> ==9634== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==9634== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==9634== For a detailed leak analysis,  rerun with: --leak-check=yes
> ==9634== For counts of detected errors, rerun with: -v
> bash-2.05b# 
> 
> 
> 

-- 
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]