#596 segfault when calling POSIX:SERVICE with two arguments

segfault
closed-fixed
Sam Steingold
clisp (525)
5
2011-04-10
2011-04-08
No

clisp segfaults when calling e.g. (service "www" "tcp").

I'm using clisp from mercurial, changeset 15330:ee288568e64a, build with --with-debug

My uname:
Linux 2.6.38-gentoo-r1 #1 SMP Tue Mar 29 17:30:38 CEST 2011 x86_64 AMD Athlon(tm) II X4 620 Processor AuthenticAMD GNU/Linux

My gcc:
gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5

glibc version: 2.11.3 (Gentoo)

Locale: de_DE.UTF-8

Backtrace:
(gdb) r
Starting program: /home/hpd/Entwicklung/src/clisp/build-g/full/lisp.run -B . -N locale -E 1:1 -q -norc -M full/lispinit.mem
STACK size: 98222 [0x7ffff7fc1e00 0x7ffff7f02090]
size_t: 8 0
ssize_t: 8 1
ffi_uintp: 8 0
FUNTAB_length=512
FUNTABR_length=66
[1]> (service "www" "tcp")

Program received signal SIGSEGV, Segmentation fault.
0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
1679 with_string_0(check_string(protocol),Symbol_value(GLO(misc_encoding)),
(gdb) bt
#0 0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
#1 0x0000000000474818 in eval_subr (fun=...) at ../src/eval.d:3592
#2 0x0000000000471b4a in eval1 (form=...) at ../src/eval.d:3084
#3 0x0000000000471565 in eval (form=...) at ../src/eval.d:2966
#4 0x0000000000590ae4 in C_read_eval_print () at ../src/debug.d:409
#5 0x000000000047cc97 in funcall_subr (fun=..., args_on_stack=2) at ../src/eval.d:5227
#6 0x000000000047bbbe in funcall (fun=..., args_on_stack=2) at ../src/eval.d:4867
#7 0x000000000048237a in interpret_bytecode_ (closure=..., codeptr=0x333d0da90, byteptr=0x333d0dad7 "\037(\a") at ../src/eval.d:6799
#8 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#9 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#10 0x0000000000496a2c in C_driver () at ../src/control.d:1999
#11 0x00000000004825ab in interpret_bytecode_ (closure=..., codeptr=0x333d0da10, byteptr=0x333d0da3d "\031\003") at ../src/eval.d:6805
#12 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#13 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#14 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#15 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#16 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#17 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#18 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#19 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#20 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#21 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#22 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#23 0x00000000005911c8 in driver () at ../src/debug.d:478
#24 0x0000000000460005 in main_actions (p=0x93a540) at ../src/spvw.d:3638
#25 0x00000000004602c0 in main (argc=11, argv=0x7fffffffe288) at ../src/spvw.d:3899
(gdb) info local
protocolz_bytelen = 262144
protocolz_data = 0x100000031 <Address 0x100000031 out of bounds>
protocolz_len = 3
protocolz_offset = 0
protocolz_string = {one_o = 6192463242502352}
ptr1 = 0x7fffffff2bc0
protocol = {one_o = 6192463242502352}
proto = 0x0
proto_buf = "D\000\000\000\000\000\000\000\016j\025糖", <incomplete sequence \363\233>
serv = {one_o = 6192463242502352}
se = 0x7fffffff32f0
(gdb)

Discussion

  • Sam Steingold
    Sam Steingold
    2011-04-10

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

     
  • Sam Steingold
    Sam Steingold
    2011-04-10

    • assigned_to: haible --> sds
    • status: open --> closed-fixed