#153 cast to char array crashes

segfault
closed-fixed
clisp (525)
5
2006-05-17
2003-04-17
No

when CLISP CVS head is compiled with gcc 3.2.1 (and 3.2.2)
with -O2, CAST segfaults:

$ ./clisp -q -norc

[1]> (use-package "FFI")
T
[2]> (def-call-out make-foreign-string
(:arguments (s c-string :in :malloc-free))
(:name "ffi_identity") (:language :stdc)
(:return-type c-pointer))
MAKE-FOREIGN-STRING
[3]> (setf *x* (make-foreign-string "abcd"))
#<FOREIGN-ADDRESS #x08192B30>
[4]> (with-c-var (p 'c-pointer *x*)
(cast p '(c-ptr (c-array uint8 4))))
#(97 98 99 100)
[5]> (with-c-var (p 'c-pointer *x*)
(cast p '(c-ptr (c-array character 4))))

*** - handle_fault error2 ! address = 0x3c0c9d00 not in
[0x20205000,0x202ea988) !
SIGSEGV cannot be cured. Fault address = 0x3c0c9d00.
Segmentation fault

this crash does not occur when CLISP is compiled with
-g -O0.

this bug might be related to bug 710737
<https://sourceforge.net/tracker/index.php?func=detail&aid=710737&group_id=1355&atid=101355>

Discussion

  • Sam Steingold

    Sam Steingold - 2003-04-20

    Logged In: YES
    user_id=5735

    <http://article.gmane.org/gmane.lisp.clisp.general/6930>

    the problem seems to be in the code generated by gcc for
    foreign.c,
    probably for the function C_cast. I tried to compile it
    without "-O2
    -fexpensive-optimizations" and all the other C modules with
    the usual
    CFLAGS, and the resulting lisp.run passed the testsuite and
    the CAST
    test. I'm currently using it.

     
  • Jörg Höhle

    Jörg Höhle - 2003-04-23

    Logged In: YES
    user_id=377168

    I don't believe in a gcc bug anymore. I believe CVS to be
    broken beyond belief, maybe by some change to lispbibl.d. I
    can get CLISP to crash just from trying to compile a macro
    definition and export that from package FFI, i.e. no foreign
    call is involved.
    http://sourceforge.net/tracker/index.php?func=detail&aid=726
    282&group_id=1355&atid=101355

    CLISP-2.30 works on my system, all with gcc-3.2.

     
  • Jörg Höhle

    Jörg Höhle - 2003-04-25

    Logged In: YES
    user_id=377168

    It looks like convert_from_foreign has a problem in the C-ARRAY[MAX] CHARACTER case, while 'CHARACTER
    (no array) works fine. Maybe due to the recent string handling changes?

     
  • Sam Steingold

    Sam Steingold - 2003-04-25

    Logged In: YES
    user_id=5735

    1. I have no idea what "ecent string handling changes" you mean.
    please investigate.

    2. "I believe CVS to be broken beyond belief" - this is an
    insult.
    please keep your civility.

     
  • Jörg Höhle

    Jörg Höhle - 2003-04-29

    Logged In: YES
    user_id=377168

    Ok, it now really looks like a GCC bug (or some lispbibl
    macros??). STACK is botched (decremented by one unit=4) in
    convert_from_foreign_array_fill() in the CHARACTER case.
    That explains both c-array character and c-array-max
    character.

    No idea how to extract a gcc bug out of this.
    Who groks the assembly code? What next?

     
  • Sam Steingold

    Sam Steingold - 2003-04-29

    Logged In: YES
    user_id=5735

    Bruno is the only person I know who can handle this.
    I am assigning this to him.

     
  • Sam Steingold

    Sam Steingold - 2003-04-29
    • assigned_to: hoehle --> haible
     
  • Jörg Höhle

    Jörg Höhle - 2003-04-30

    Logged In: YES
    user_id=377168

    Looking at the assembly section for
    pushSTACK(array);
    var object encoding = O(foreign_encoding);
    I can see that a single
    addl $4, %ebx
    is missing in between. It re-appears when I add some printf+
    nobject_out(STACK_0) inbetween.

    The readline bug could be very similar.
    BTW, I'm using gcc-3.2 on SuseLinux 8.1

     
  • Sam Steingold

    Sam Steingold - 2003-04-30

    Logged In: YES
    user_id=5735

    great! so you now have enough information for a GCC bug report.
    all you need to do is to extract a small part of the code
    that exhibits
    this behavior and submit it to the GCC people.
    will you do that?

     
  • Sam Steingold

    Sam Steingold - 2003-05-03

    Logged In: YES
    user_id=5735

    I checked in a workaround (disabling STACK_register for GCC3).
    you still need to submit a GCC bug report.

     
  • Sam Steingold

    Sam Steingold - 2003-05-03
    • labels: 355966 --> clisp
     
  • Jörg Höhle

    Jörg Höhle - 2003-05-09

    Logged In: YES
    user_id=377168

    The bug is one in gcc, a gcc-bug-report was submitted,
    resolution is therefore pending until further notice. Please
    read
    http://article.gmane.org/gmane.lisp.clisp.devel/9914
    and the link there to gnats.

    Summary of work-arounds known so far. One of
    o compile CLISP without -O (or with -O0)
    o configure --without-unicode (no indirect jump via
    cstombs()).
    o go back to gcc-2.X (<3.0)
    o disable use of register variable for STACK (currently in
    CVS:lispbibl.d)
    o configure --with-dynamic-modules (which disables the
    register variable currently)
    o recompile only foreign.d and stream.d without -O2, after
    you built a CLISP the normal way.

    Regards,
    Jrg Hhle.

     
  • Jörg Höhle

    Jörg Höhle - 2006-05-17
    • assigned_to: haible --> hoehle
    • status: open --> closed-fixed
     
  • Jörg Höhle

    Jörg Höhle - 2006-05-17

    Logged In: YES
    user_id=377168

    I temporarily re-enabled STACK_register for gcc-3.3 and checked
    + gcc-3.3.5 (Ubuntu Hoary) (current CVS)
    + gcc-3.3.6 (Ubuntu Breezy) (current CVS)
    Both the readline and cast to char array crashes go away.

    I'll nevertheless leave STACK_register disabled for 3.3 in
    lispbibl.d: be conservative just in case somebody uses an
    old gcc-3.0-3.3.3. People regularly upgrading will have 3.4
    or 4.x anyway.

     
  • Jörg Höhle

    Jörg Höhle - 2006-05-17

    Logged In: YES
    user_id=377168

    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).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks