This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Emacs can't start-process more than 30~40 processes (Was: Re: Emacs w3m `w3m-toggle-inline-images' cause segfault)


On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote:
>Haojun Bao <baohaojun@gmail.com> writes:
>
>> I have reduced the test case in this mail 
>>   http://cygwin.com/ml/cygwin/2009-07/msg00111.html
>> to a simpler one:
>>
>>     $/bin/emacs --batch -q  --execute '(let ((num 0))
>>       (while (< num 30)
>>         (setq num (+ num 1))
>>         (message "num is %d" num)
>>         (start-process "hello" nil "/usr/bin/echo")))'
>>     
>> Emacs will coredump at the 30th process it tries to start on my XP.
>>
>> Now I think this should seem familiar to the experts. I tried to gdb it,
>> the backtrace shows segfault is happening at the same place 
>> (#0 0x610949d8 in fhandler_pipe::create () from /usr/bin/cygwin1.dll)
>>
>> You might need to tweak the (< num 30) to (< num 40) or bigger, also, to
>> use gdb on it, you need write the lisp into a file and use `-l' to load
>> the file:
>>
>> cat > ~/2.el <<End
>> (let ((num 0))
>>   (while (< num 40)
>>     (setq num (+ num 1))
>>     (message "num is %d" num)
>>     (start-process "hello" nil "/usr/bin/echo")))
>> End
>>
>> gdb --args ./emacs --batch -q  -l ~/2.el
>
>I have debugged it again, and I think I have more clue. I have read the
>how-cygheap-works.txt, and this might be a known problem.
>
>It's because the cygheap space has been used up. With Procexp, I can see
>cygwin1.dll is based 0x61000000, with size 0x300000 (3M). When segfault
>is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called
>with a increase of 
>    (gdb) p sbs
>    $16 = 65544
>This will increase cyghead to 0x6165e92c, but from Proxexp I can see
>cygncurses-9.dll is based at 0x61650000.
>
>Besides, this code snippet from pipe.cc fhandler_pipe::create didn't
>check for NULL pointer, and directly caused the segfault.
>
>      fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev);
>      fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev);
>
>//bhj: we should check NULL here.

Not necessarily.  We don't expect these functions to return NULL.  It
would be interesting to know how many fds are open at this point.  If it
is a large number then maybe we have to start enforcing an fd max.  If
it is a "small" number then something is wrong and we're allocating too
much of the cygheap.  The cygheap was always supposed to be relatively
small.  Maybe we're abusing it too much in 1.7.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]