#386 back_trace is not initialized when it is a register

build problems
closed-fixed
Sam Steingold
clisp (525)
5
2007-07-08
2006-12-02
Larry Valkama
No

Hi,

My ambition is to keep an track of the build procedure on hpux 11.11 parisc, that doesn't work today with clisp.

I hope to annotate this bug ticket with all relevant info as soon as possible.

As an apertif, lets start with a simple gcc problem:

Currently it stops at this:

The compile halted when compiling malloc/gmalloc.c.
The lines 240 and 360 differ at:

http://clisp.cvs.sourceforge.net/clisp/clisp/src/malloc/gmalloc.c?view=markup

I made the lines 240 and 360 be equal to:
__ptr_t (*__morecore) PP ((ptrdiff_t __size)) = __default_morecore;

I dont know what I'm doing but atleast the compile went through.

Now instead I got an bus error when the interpreter tried to cold boot.

Discussion

  • Larry Valkama
    Larry Valkama
    2006-12-04

    • priority: 5 --> 1
     
  • Jörg Höhle
    Jörg Höhle
    2006-12-07

    Logged In: YES
    user_id=377168
    Originator: NO

    Looking at gmalloc.c, it looks like you should have done the opposite: change line 360 to use __malloc_ptrdiff_t.
    But that will probably not help you with sigsegv or sigbus when running lisp.run to build lispimag.mem. For that you need to provide more information and a gdb backtrace.

     
  • Larry Valkama
    Larry Valkama
    2006-12-09

    • assigned_to: haible --> nobody
     
  • Larry Valkama
    Larry Valkama
    2006-12-09

    Logged In: YES
    user_id=188676
    Originator: YES

    File Added: clisp-debug.txt

     
  • Larry Valkama
    Larry Valkama
    2006-12-09

    gdb info

     
    Attachments
  • Larry Valkama
    Larry Valkama
    2006-12-09

    Logged In: YES
    user_id=188676
    Originator: YES

    changed gmalloc and runned gdb, see attachment.. will provide more info as needed.

     
  • Larry Valkama
    Larry Valkama
    2006-12-22

    Logged In: YES
    user_id=188676
    Originator: YES

    clisp builds upto ANSI CL, ie no modules yet.

    apply these workarounds:

    in src/spvw.d
    3269 # The argv_* variables now have their final values.
    3270 # Analyze the environment variables determining the locale.
    3271 # Deal with LC_CTYPE.
    + back_trace = NULL;
    3272 init_ctype();

    It seems back_trace is initialized to NULL when declared but it has no effect.
    Instead it contains some garbage, bt.bt_next == bt.bt_function for example.

    also change src/malloc/gmalloc.c:
    change line 360 to use __malloc_ptrdiff_t.

    This made the compilation through all but modules, atleast an full ANSI CL clisp can be started and seems to be working and running ok.

     
  • Sam Steingold
    Sam Steingold
    2007-06-20

    Logged In: YES
    user_id=5735
    Originator: NO

    gmalloc prototype has been fixed in the CVS, thank.
    does the back_trace reinit actually make a difference?

     
  • Sam Steingold
    Sam Steingold
    2007-06-20

    Logged In: YES
    user_id=5735
    Originator: NO

    try this:

    $ cat > z.c <<EOF
    #include <stdio.h>
    int global_var = 42;
    void main (void) { printf("%d\n",global_var); }
    EOF
    $ gcc z.c -o z
    $ ./z

    does "42" get printed?

     
  • Larry Valkama
    Larry Valkama
    2007-07-01

    Logged In: YES
    user_id=188676
    Originator: YES

    > does "42" get printed?

    yes.

     
  • Sam Steingold
    Sam Steingold
    2007-07-01

    Logged In: YES
    user_id=5735
    Originator: NO

    then I don't see how the back_trace reinit can make a difference.
    could you please try to create a small stand-alone test case?

     
  • Larry Valkama
    Larry Valkama
    2007-07-05

    Logged In: YES
    user_id=188676
    Originator: YES

    Probable cause summary: back_trace is declared at several places depending on IFDEFs but only one place is initializing with NULL

    Details:

    back_trace was never initialized before beeing used:

    back_trace can be initialized at line 287:
    #if !defined(back_trace_register)

    On hpux 11.11 parisc back_trace isn't declared at that point.Instead it is probably declared in lispbibl.d An fprintf of back_trace shows that it doesn't contains NULL when entering main().
    In spvw.d around line 3279 init_memory() is called.This function doesn't like back_trace beeing non NULL.

    So back_trace isn't declared in in spvw.d, but probably declared in lispbibl.d around row 11688.
    But spvw.d initialize it to NULL, whereas lispbibl.d doesn't.

    Placing back_trace = NULL before init_memory() seem to
    help.

    Patch:

    --- src/cvs/clisp-20070704/src/spvw.d 2007-04-29 03:00:17.000000000 +0200
    +++ spvw.d 2007-07-04 16:15:01.000000000 +0200
    @@ -285,7 +285,7 @@ local int exitcode;

    # During the execution of a SUBR, FSUBR: the current SUBR resp. FSUBR
    #if !defined(back_trace_register)
    - global p_backtrace_t back_trace = NULL;
    + global p_backtrace_t back_trace;
    #endif
    #ifdef HAVE_SAVED_back_trace
    global p_backtrace_t saved_back_trace;
    @@ -3265,6 +3265,7 @@ global int main (argc_t argc, char* argv
    SP_anchor = (void*)SP();
    if (!(setjmp(original_context) == 0)) goto end_of_main;
    # Initialize memory and load a memory image (if specified).
    + back_trace = NULL;
    if (init_memory(&argv1) < 0) goto no_mem;
    /* if the image was read from the executable, argv1.argv_memfile was
    set to exec name and now it has to be propagated to argv2.argv_memfile

     
  • Sam Steingold
    Sam Steingold
    2007-07-08

    Logged In: YES
    user_id=5735
    Originator: NO

    please open a new bug report for further troubles.

     
  • Sam Steingold
    Sam Steingold
    2007-07-08

    • assigned_to: nobody --> sds
    • summary: general build on hpux 11.11 parisc --> back_trace is not initialized when it is a register
    • priority: 1 --> 5
    • status: open --> closed-fixed
     
  • Sam Steingold
    Sam Steingold
    2007-07-08

    Logged In: YES
    user_id=5735
    Originator: NO

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).