#200 Very large form causing segfault in compiled code

segfault
closed-fixed
clisp (525)
5
2004-02-08
2004-02-04
No

Running the gcl random tester on very large terms, I've
found it occasionally causes the compiler to generate
code that immediately segfaults. Hand-pruning the
failing form reduced its size by a factor of 4, but
it's still very large. See the attached file.

This was in clisp built 2 Feb 2004 at ~5PM CST, on an
x86 under Redhat 9.

Discussion

  • Paul F. Dietz

    Paul F. Dietz - 2004-02-04

    file that when loaded exhibits the bug

     
  • Sam Steingold

    Sam Steingold - 2004-02-05

    Logged In: YES
    user_id=5735

    Program received signal SIGSEGV, Segmentation fault.
    0x0042cbc3 in interpret_bytecode_ (closure={one_o = 434543061},
    codeptr=0x19e69638, byteptr_in=0x19e6964a "") at eval.d:5829
    5829 switch (*byteptr++)
    (gdb) where
    #0 0x0042cbc3 in interpret_bytecode_ (closure={one_o =
    434543061},
    codeptr=0x19e69638, byteptr_in=0x19e6964a "") at eval.d:5829
    #1 0x0042a941 in apply_closure (closure={one_o = 434543061},
    args_on_stack=0, args={one_o = 5989537}) at eval.d:4754
    #2 0x00428245 in apply (fun={one_o = 434543061},
    args_on_stack=0, other_args=
    {one_o = 1610423315}) at eval.d:3903
    #3 0x00436975 in C_apply (argcount=0,
    rest_args_pointer=0xf3025c)
    at control.d:318
    #4 0x00426858 in eval_subr (fun={one_o = 5970978}) at
    eval.d:3445
    #5 0x00424d1a in eval1 (form={one_o = 1610417571}) at
    eval.d:2922
    #6 0x0042499b in eval (form={one_o = 1610417571}) at
    eval.d:2808
    #7 0x00425aa5 in eval_subr (fun={one_o = 5974458}) at
    eval.d:3224
    #8 0x00424d1a in eval1 (form={one_o = 1610417579}) at
    eval.d:2922
    #9 0x0042499b in eval (form={one_o = 1610417579}) at
    eval.d:2808
    #10 0x00437879 in C_let () at control.d:671
    #11 0x00425415 in eval_fsubr (fun={one_o = 433630093}, args=
    {one_o = 1610416283}) at eval.d:3081
    #12 0x00424db1 in eval1 (form={one_o = 1610416363}) at
    eval.d:2938
    #13 0x0042499b in eval (form={one_o = 1610416363}) at
    eval.d:2808
    #14 0x00437a7c in C_letstern () at control.d:716
    #15 0x00425415 in eval_fsubr (fun={one_o = 433630113}, args=
    {one_o = 1610416411}) at eval.d:3081
    #16 0x00424db1 in eval1 (form={one_o = 1610416539}) at
    eval.d:2938
    #17 0x0042499b in eval (form={one_o = 1610416539}) at
    eval.d:2808
    #18 0x0041f825 in eval_5env (form={one_o = 1610416539}, var_env=
    {one_o = 5989537}, fun_env={one_o = 5989537}, block_env=
    {one_o = 5989537}, go_env={one_o = 5989537}, decl_env=
    {one_o = 1610602019}) at eval.d:961
    #19 0x0041f87e in eval_noenv (form={one_o = 1610416539}) at
    eval.d:973
    #20 0x0043c4f8 in C_eval () at control.d:2108
    #21 0x0042f58f in interpret_bytecode_ (closure={one_o =
    433679777},
    codeptr=0x19d9685c, byteptr_in=0x19d96872 "") at eval.d:6855
    #22 0x00427b5a in eval_closure (closure={one_o = 433679777})
    at eval.d:3747
    #23 0x00424d58 in eval1 (form={one_o = 1610423243}) at
    eval.d:2929
    #24 0x0042499b in eval (form={one_o = 1610423243}) at
    eval.d:2808
    #25 0x0053d276 in C_read_eval_print () at debug.d:311
    #26 0x0042b88a in funcall_subr (fun={one_o = 5971650},
    args_on_stack=2)
    at eval.d:5198
    #27 0x0042ab84 in funcall (fun={one_o = 5995053},
    args_on_stack=2)
    at eval.d:4807
    #28 0x0042f458 in interpret_bytecode_ (closure={one_o =
    434541441},
    codeptr=0x19e377bc, byteptr_in=0x19e377ce "a\031\r ") at
    eval.d:6849
    #29 0x0042c852 in funcall_closure (closure={one_o = 434541441},
    args_on_stack=0) at eval.d:5638
    #30 0x0042ab3b in funcall (fun={one_o = 434541441},
    args_on_stack=0)
    at eval.d:4802
    #31 0x0043b9ce in C_driver () at control.d:1938
    #32 0x0042f58f in interpret_bytecode_ (closure={one_o =
    434337849},
    codeptr=0x19e3776c,
    byteptr_in=0x19e3777e "\031\001N\001\002N\001\001N\001")
    at eval.d:6855
    #33 0x0042c852 in funcall_closure (closure={one_o = 434337849},
    args_on_stack=0) at eval.d:5638
    #34 0x0042ab3b in funcall (fun={one_o = 434337849},
    args_on_stack=0)
    at eval.d:4802
    #35 0x0042ffed in interpret_bytecode_ (closure={one_o =
    434535709},
    codeptr=0x19dbe154, byteptr_in=0x19dbe166
    "U\031O\aO\031lU\031\022\032")
    at eval.d:6905
    #36 0x0042c852 in funcall_closure (closure={one_o = 434535709},
    args_on_stack=0) at eval.d:5638
    #37 0x0042ab3b in funcall (fun={one_o = 434535709},
    args_on_stack=0)
    at eval.d:4802
    #38 0x0053d5dc in driver () at debug.d:380
    #39 0x0041aa3e in main (argc=7, argv=0x3f2c10) at spvw.d:2973
    (gdb) p byteptr
    = (const uintB *) 0xf801af16 <Address 0xf801af16 out of
    bounds>
    (gdb) p byteptr-1
    = (const uintB *) 0xf801af15 <Address 0xf801af15 out of
    bounds>
    (gdb) p byteptr-2
    = (const uintB *) 0xf801af14 <Address 0xf801af14 out of
    bounds>
    (gdb) p byteptr-20
    = (const uintB *) 0xf801af02 <Address 0xf801af02 out of
    bounds>
    (gdb) p byteptr-200
    = (const uintB *) 0xf801ae4e <Address 0xf801ae4e out of
    bounds>
    (gdb) up
    #1 0x0042a941 in apply_closure (closure={one_o = 434543061},
    args_on_stack=0, args={one_o = 5989537}) at eval.d:4754
    4754
    interpret_bytecode(closure,codevec,CCV_START_NONKEY); #
    process By
    tecode starting at Byte 8
    (gdb) p codevec
    = {one_o = 434542137}
    (gdb) xout codevec
    #<varobject type=13 address=0x19E69638>{one_o = 434542137}
    (gdb) zout codevec
    #(3 0 1 0 8 0 0 0 0 0 0 43 4 127 9 0 0 127 8 0 1 127 6 0 2
    127 2 0 3 104 0 1
    176 142 1 128 80 220 145 0 49 128 120 221 180 143 208 128
    97 222 144 0 49 128
    71 177 51 0 47 226 206 80 2 207 81 16 11 107 11 51 1 53 17
    20 209 16 13 211
    17 20 115 1 53 233 234 114 218 115 2 62 144 1 45 128 89
    236 237 104 2 0 115 1
    52 115 1 53 115 0 54 142 208 129 118 222 27 129 81 218 219
    145 1 47 64 27 129
    115 104 0 0 145 0 47 255 181 223 104 1 3 145 1 45 255 172
    27 129 95 104 0 1
    144 0 50 129 87 224 145 0 45 255 155 27 129 78 179 37 7
    255 147 27 129 70 235
    173 51 1 50 22 1 29 255 188 27 129 47 104 0 2 172 142 12
    108 22 1 29 255 173
    27 129 32 222 27 128 241 243 173 51 1 50 22 1 29 129 18 27
    129 25 75 27 130
    110 222 27 130 98 3 29 27 130 126 3 31 27 130 121 3 33 27
    130 116 101 35 173
    51 1 50 22 1 29 130 121 27 130 146 6 0 0 27 130 122 101 38
    145 0 50 130 133
    27 128 119 6 1 1 27 128 104 101 44 101 45 97 1 19 8 0 0 1
    0 17 24 1 0 20 104
    2 1 145 1 45 98 3 46 80 128 75 6 4 0 81 27 128 68 6 8 0 27
    128 103 3 52 81 27
    128 105 101 40 144 0 49 25 101 41 114 211 6 1 3 16 42 3 43
    17 20 145 1 46 42
    104 0 2 176 145 1 49 34 104 0 1 104 1 0 179 144 1 47 255
    165 104 1 1 144 0 49
    255 157 3 47 11 1 3 20 234 114 202 145 1 48 130 11 101 48
    14 49 16 49 3 46 80
    30 101 50 187 104 9 3 142 1 255 159 101 51 188 115 2 59
    115 1 55 51 0 54 20
    144 1 46 255 147 201 81 20 51 1 53 17 20 114 150 143 216
    129 215 27 55 133 0
    172 239 145 1 50 120 22 1 133 0 172 238 145 1 50 254 250 6
    1 0 22 1 16 22 3
    23 17 20 172 143 12 7 242 173 144 1 49 254 232 22 1 28 10
    244 144 0 49 254
    235 179 51 0 45 6 0 1 38 53 128 124 3 54 27 129 60 3 55 27
    129 55 164 27 129
    51 3 56 27 129 46 3 57 27 129 41 213 27 129 37 3 58 27 129
    32 162 27 129 28 3
    52 27 129 23 161 27 129 19 101 61 181 144 1 46 128 134 101
    62 222 144 1 45
    128 126 3 66 80 6 238 184 51 2 55 81 20 51 1 53 27 128 155
    101 70 104 3 2 50
    217 27 128 130 161 27 16 104 0 1 142 145 119 172 109 73 1
    56 1 158 52 22 1 16
    74 175 109 75 1 157 52 248 51 1 53 17 27 128 197 101 52
    101 59 104 2 0 179
    104 4 2 115 3 53 115 1 53 142 208 44 104 1 2 101 60 144 1
    50 255 148 101 63
    101 64 101 65 104 4 2 115 2 53 101 64 104 5 0 115 2 53 104
    5 3 115 2 53 115 3
    53 145 1 47 255 130 101 67 101 68 101 69 115 1 52 115 1 52
    3 66 80 4 6 5 2 81
    20 101 39 144 1 50 255 119 6 2 1 20 115 1 59 114 200 101
    71 101 72 115 2 58
    50 200 20 142 208 255 109 222 27 49 101 76 178 51 2 55 38
    77 128 0 222 27 21
    222 27 8 88 0 74 0 0 2 133 0 172 234 145 1 50 120 22 1 133
    0 172 234 145 1 50
    101 22 1 14 49 16 49 17 133 0 172 239 145 1 50 73 201 248
    71 78 6 87 79 168
    22 4 72 16 80 3 81 16 42 167 18 2 20 51 2 53 20 56 1 50
    179 25 10 133 0 172
    239 145 1 50 120 22 1 76 176 234 246 142 208 253 142 178
    36 30 253 142 104 1
    2 101 32 144 1 49 253 137 3 34 20 115 2 53 115 0 54 172
    142 12 253 128 22 1
    28 28 104 0 3 144 0 45 253 130 3 36 20 144 0 49 253 192
    179 36 37 253 123 101
    39 104 1 1 50 208 213 25 10)
    {one_o = 434542137}
    (gdb) down
    #0 0x0042cbc3 in interpret_bytecode_ (closure={one_o =
    434543061},
    codeptr=0x19e69638, byteptr_in=0x19e6964a "") at eval.d:5829
    5829 switch (*byteptr++)
    (gdb) zout codeptr
    #<ADDRESS #x19E69638>
    {one_o = 434542136}
    (gdb) p private_SP
    = (SPint *) 0x22ac3c
    (gdb) p private_SP_length
    = 19
    (gdb) p *private_SP
    = 5056505
    (gdb)

     
  • Sam Steingold

    Sam Steingold - 2004-02-05
    • assigned_to: sds --> haible
     
  • Paul F. Dietz

    Paul F. Dietz - 2004-02-08

    Logged In: YES
    user_id=638212

    I've attached another (even larger) file that causes a
    segfault when loaded. This file has also been manually
    pruned as far as I could.

     
  • Paul F. Dietz

    Paul F. Dietz - 2004-02-08

    Another bug example

     
  • Sam Steingold

    Sam Steingold - 2004-02-08

    Logged In: YES
    user_id=5735

    in both bug cases, the immediate cause of the crash is the
    incorrect (HUGE!) default label in a FMPHASH bytecode.

     
  • Sam Steingold

    Sam Steingold - 2004-02-08

    Logged In: YES
    user_id=5735

    the bad label is because assemble-LAP computes a zero-distance
    jump for the default label of a JMPHASH (written as "128 0" and
    later interpreted as a 6 byte distance)

     
  • Sam Steingold

    Sam Steingold - 2004-02-08
    • assigned_to: haible --> sds
    • status: open --> closed-fixed
     
  • Sam Steingold

    Sam Steingold - 2004-02-08

    Logged In: YES
    user_id=5735

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

     

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

Sign up for the SourceForge newsletter:





No, thanks