On Sun, Jan 20, 2013 at 6:59 PM, Rob Browning <r...@defaultvalue.org> wrote:
> Christopher Wellons <mosquito...@gmail.com> writes:
>
>> Evaluating this code, which is supposed to create a pipe process,
>> results in an immediate segfault.
>>
>> (let ((process-connection-type nil))
>>   (start-process "" nil nil))
>>
>> The key is the third argument, the PROGRAM, being nil. Set that to
>> non-nil and it doesn't crash.
>
> Hmm, pasting that into the *scratch* buffer here and evaluating it via
> Esc-S-x or M-C-x doesn't cause a crash (in emacs24 or emacs24-lucid).
>
> If you have time, could you try again with 24.2+1-2 when it makes it to
> sid (should be shortly)?  You might also want to install the new
> emacs24-dbg package which will allow gdb to make more sense.
>
> Oh, and if you can, try with "emacs -Q" too, to see if local
> customizations might be involved.
>
> Thanks

I tested it with -Q before submitting, so that's not it. I submitted
the report from a 32-bit system but I'm also seeing it on x86_64
(Ubuntu 12.04, my own Emacs 24.1.1 build). A friend has informed me he
also gets it on his Mac with 24.1.1 (homebrew I think). I'm also
seeing it with Emacs 23.4, both sid's emacs23 package and my own
non-debian build, on the system from where I submitted this report.

I just tried it on third machine, a laptop running x86_64 wheezy using
my own Emacs 24.1.1 build and, curiously, like you I'm *not* seeing
the crash on it.

I don't see an emacs24-dbg yet, so here's a backtrace of a non-debian
build. I'll keep an eye out for 24.2+1-2.


(gdb) run -Q -l tmp.el
Starting program: /tmp/emacs-24.2/bin/emacs -Q -l tmp.el
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xb6254b70 (LWP 30130)]
[New Thread 0xb56ffb70 (LWP 30131)]

Program received signal SIGSEGV, Segmentation fault.
create_pty (process=143565397) at process.c:1996
1996      FD_SET (inchannel, &input_wait_mask);
(gdb) bt
#0  create_pty (process=143565397) at process.c:1996
#1  Fstart_process (nargs=3, args=0xbfffe820) at process.c:1515
#2  0x081ac3ad in eval_sub (form=142043022) at eval.c:2321
#3  0x081ac637 in Fprogn (args=<optimized out>) at eval.c:364
#4  0x081af63f in Flet (args=142043030) at eval.c:1119
#5  0x081ac3df in eval_sub (form=form@entry=142043062) at eval.c:2297
#6  0x081cf45b in readevalloop (readcharfun=readcharfun@entry=143561493,
    stream=stream@entry=0x0, sourcename=-1248716735,
    sourcename@entry=-1248713831, printflag=0, unibyte=unibyte@entry=138822938,
    readfun=138822938, start=138822938, end=138822938) at lread.c:1837
#7  0x081cfb5a in Feval_buffer (buffer=143561493, printflag=138822938,
    filename=-1248713831, unibyte=138822938, do_allow_print=138822962)
    at lread.c:1898
#8  0x081acd66 in Ffuncall (nargs=nargs@entry=6, args=args@entry=0xbfffeb20)
    at eval.c:3017
#9  0x081e319c in exec_byte_code (bytestr=<optimized out>, vector=136889893,
    maxdepth=24, args_template=138822938, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0x0) at bytecode.c:785
#10 0x081ac825 in funcall_lambda (fun=136889805, nargs=nargs@entry=4,
    arg_vector=arg_vector@entry=0xbfffecb0) at eval.c:3232
#11 0x081acbeb in Ffuncall (nargs=nargs@entry=5, args=args@entry=0xbfffecac)
    at eval.c:3062
#12 0x081ad03f in call4 (fn=139126114, arg1=arg1@entry=-1248713831,
    arg2=arg2@entry=-1248713831, arg3=138822938, arg4=138822962) at eval.c:2819
#13 0x081cfeb9 in Fload (file=-1248713591, noerror=138822938,
---Type <return> to continue, or q <return> to quit---
    nomessage=138822962, nosuffix=138822938, must_suffix=<optimized out>)
    at lread.c:1255
#14 0x081acd66 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0xbfffeef0)
    at eval.c:3017
#15 0x081e319c in exec_byte_code (bytestr=<optimized out>, vector=137083349,
    maxdepth=88, args_template=args_template@entry=1028, nargs=nargs@entry=1,
    args=<optimized out>, args@entry=0xbffff074) at bytecode.c:785
#16 0x081ac884 in funcall_lambda (fun=137083301, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0xbffff074) at eval.c:3166
#17 0x081acbeb in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xbffff070)
    at eval.c:3062
#18 0x081e319c in exec_byte_code (bytestr=<optimized out>, vector=137070725,
    maxdepth=72, args_template=args_template@entry=0, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0xbffff228) at bytecode.c:785
#19 0x081ac884 in funcall_lambda (fun=137070677, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0xbffff228) at eval.c:3166
#20 0x081acbeb in Ffuncall (nargs=nargs@entry=1, args=args@entry=0xbffff224)
    at eval.c:3062
#21 0x081e319c in exec_byte_code (bytestr=<optimized out>, vector=137067933,
    maxdepth=32, args_template=args_template@entry=0, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0xbffff330) at bytecode.c:785
#22 0x081ac884 in funcall_lambda (fun=fun@entry=137067885, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0xbffff330) at eval.c:3166
#23 0x081abd2e in apply_lambda (fun=137067885, args=<optimized out>)
    at eval.c:3109
---Type <return> to continue, or q <return> to quit---
#24 0x081ac06e in eval_sub (form=form@entry=139027134) at eval.c:2413
#25 0x081aec1d in Feval (form=139027134, lexical=138822938) at eval.c:2203
#26 0x0813e299 in top_level_2 () at keyboard.c:1169
#27 0x081ab1c0 in internal_condition_case (
    bfun=bfun@entry=0x813e280 <top_level_2>, handlers=138854018,
    hfun=hfun@entry=0x813f8c0 <cmd_error>) at eval.c:1514
#28 0x0813ea85 in top_level_1 (ignore=ignore@entry=138822938) at keyboard.c:1177
#29 0x081ab0eb in internal_catch (tag=138851970,
    func=func@entry=0x813ea20 <top_level_1>, arg=138822938) at eval.c:1271
#30 0x0813f3dc in command_loop () at keyboard.c:1132
#31 recursive_edit_1 () at keyboard.c:759
#32 0x0813f6ed in Frecursive_edit () at keyboard.c:823
#33 0x08059bb0 in main (argc=<optimized out>, argv=0xbffffa64) at emacs.c:1715


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to