[Ecls-list] Problem building from git

Fri Jan 30 10:27:07 UTC 2009

Hi!
You can produce some kind of backtrace using gdb.
Try:
   > gdb ./ecl_min
  (gdb) set args compile
  (gdb) run
....
  (gdb) backtrace

In my 64bit machine, it produced:

(gdb) run
;*** Lisp core booted ****
ECL (Embeddable Common Lisp)

Breakpoint 2, cl_error (narg=9, eformat=0x5cea10)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/error.d:294
294             ecl_enable_interrupts();
(gdb) backtrace
#0  cl_error (narg=9, eformat=0x5cea10)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/error.d:294
#1  0x000000000043457c in not_a_binary_stream (s=0x789a00)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/file.d:4547
#2  0x000000000042cafc in not_binary_write_byte (c=0x1a2, strm=0x789a00)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/file.d:148
#3  0x000000000042d458 in generic_write_vector (strm=0x789a00, data=0x796a28,
    start=0, end=7)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/file.d:529
#4  0x00000000004324de in si_do_write_sequence (seq=0x796a28, stream=0x789a00,
    s=0x3, e=0x1)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/file.d:3903
#5  0x000000000046d0aa in ecl_namestring (x=0x615818, truncate_if_unreadable=1)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/pathname.d:929
#6  0x000000000046d3e5 in cl_namestring (x=0x615818)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/pathname.d:1004
---Type <return> to continue, or q <return> to quit---
#7  0x000000000046cbaa in si_coerce_to_filename (pathname_orig=0x615850)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/pathname.d:798
#8  0x0000000000473073 in si_file_kind (filename=0x615850,
    follow_links=0x5c59b0)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/unixfsys.d:194
#9  0x00000000004728bd in cl_load (narg=1, source=0x615888)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/load.d:522
#10 0x00000000004069d2 in si_simple_toplevel ()
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/cinit.d:92
#11 0x000000000048d4f0 in APPLY_fixed (n=0, fn=0x40695a <si_simple_toplevel>,
    x=0x2a955570a8)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/apply.d:675
#12 0x0000000000415d47 in ecl_apply_from_stack_frame (frame=0x7fbfffef80,
    x=0x5d2ee0)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/eval.d:76
#13 0x0000000000416442 in cl_funcall (narg=1, function=0x5d2ee0)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/eval.d---Type
<return> to continue, or q <return> to quit---
:204
#14 0x0000000000406b5d in main (argc=2, args=0x7fbffff178)
    at /hardmnt/tharpe0/sra/serra/CommonLisp/Implementation/src/ecl/src/c/cinit.d:127

G.

On Fri, Jan 30, 2009 at 10:10 AM, Jeronimo Pellegrini <jpn at aleph0.info> wrote:
> Hi!
>
> On Fri, Jan 30, 2009 at 09:40:59AM +0100, Juan Jose Garcia-Ripoll wrote:
>> Hi, these are two separate issues. One is an actual typo in the
>> Unicode code int->cl_fixnum replacement is ok. I just messed it up
>> (Incidentally, it cannot be a char, for it is a Unicode character and
>> it can be as large as #x10FFFF) and will upload a fix in a few
>> minutes.
>
> Yes; I already got it here... (Thank you!)
>
>> The amd64 issue is different. There are problems right now with the
>> 64-bits intel architecture. My computational facilities have been
>> dramatically reduced in the last months, and this week dreamhost has
>> decided to blacklist my office IP address, so that I am also
>> experiencing problems to reach a node I pay for. Add that to the fact
>> I still do not have ADSL at home and you will find a nice picture :-)
>> Damn, it seems I am all the time whining to the mailing list, hehe.
>
> Is there anything I can do to help? If you tell me how to produce some
> kind of backtrace or debugging info, I can send it to you.
>
> It looks like ecl_min doesn't accept the "compile" argument just as if it
> was garbage:
>
>  ./ecl_min
>  ;*** Lisp core booted ****
>  ECL (Embeddable Common Lisp)
>
>  >    ;; this went OK
>
>
>
> ./ecl_min abc
> ;*** Lisp core booted ****
> ECL (Embeddable Common Lisp)
>
> Internal or unrecoverable error in:
>
> Lisp initialization error.
>
>  [22: Invalid argument]
> Aborted
>
>
>
>
> ./ecl_min compile
> ;*** Lisp core booted ****
> ECL (Embeddable Common Lisp)
>
> Internal or unrecoverable error in:
>
> Lisp initialization error.
>
>  [22: Invalid argument]
> Aborted
>
>
> J.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
>

-- 
The basic tool for the manipulation of reality is the manipulation of
words. If you can control the meaning of words, you can control the
people who must use the words.
                   How To Build A Universe That Doesn't Fall Apart Two
Days Later
                   Philip K. Dick