A process is not necesarily the real "problem". All
process are processes that their parent has NOT done a wait(2) yet.
Since these processes have called exit(2), they must hang
around until a wait(2) is completed so that the exit status can be
returned to the parent.
You need to unde
--- Ven 27/11/09, Tatsuro MATSUOKA ha scritto:
> Hello
>
> When linking gnuplot-tikz.lua.exe, which is part of gnuplot
> for a lua related terminal, the following
> error appeared
>
> gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o
> gnuplot-tikz.lua.exe -lpangocairo-1.0
> -lcairo
> -lpangof
Hello
When linking gnuplot-tikz.lua.exe, which is part of gnuplot for a lua related
terminal, the following
error appeared
gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o gnuplot-tikz.lua.exe
-lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lpixman-1 -lglitz -lpng12 -lxcb-render-util -lXrender
-lx
2009/11/27 Dave Steenburgh
>
> cgf wrote:
> > Defunct processes are not necessarily indicative of a cygwin problem.
> > This could easily be a problem with gnuplot.
>
> Given the sum of my own limited knowledge of the problem at hand (in
> summary: every program involved is in my local cygwin dire
cgf wrote:
> Defunct processes are not necessarily indicative of a cygwin problem.
> This could easily be a problem with gnuplot.
Given the sum of my own limited knowledge of the problem at hand (in
summary: every program involved is in my local cygwin directory), I
figured it was best to ask here
Here is the tail end of an strace of the hanging cvs process.
Jeremy
cvs.strace.out
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cy
I have cvs on a client machine connecting to a host over ssh. The cvs
procedure finishes, but the connection does not terminate until I hit
ctrl-c. The cvs process is then left running on the host. Regular ssh
connections (ie interactive login) do not have this problem.
The host machine is Cygwin
On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:
>On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
>> I wonder if some process has created the file in
>> question and still has it open. Then a call to
>> create, and a call to unlink, will both fail.
>
>But the call to open i
On Thu, Nov 26, 2009 at 01:52:45PM -0500, Dave Steenburgh wrote:
>It is my understanding that this problem is not easily reproducible.
>Well, I've been reproducing it locally since last night. ?I'm going to
>try leaving every cygwin-related process as-is as long as necessary,
>in the hope of beatin
On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
> I wonder if some process has created the file in
> question and still has it open. Then a call to
> create, and a call to unlink, will both fail.
But the call to open is failing (the fd returned is -1),
which is why the unlink() is exec
Am 26.11.2009, 16:58 Uhr, schrieb Corinna Vinschen
:
This circumvents a few installation problems and decouples the Cygwin
homedir by default from the Windows profile directory, which
especially starting with Vista results in performance problems due to
the new Explorer behaviour conc
I wonder if some process has created the file in
question and still has it open. Then a call to
create, and a call to unlink, will both fail.
You might not see the file until the process
closes it or dies ...
Just a wondering ...
The procexp tool from sysinternals.com might
reveal an open file
Reinier Post writes:
" curl
ftp://ftp.debian.org/debian/pool/main/c/calcoo/calcoo_1.3.16.orig.tar.gz
" | tar zxvf -
"
" hangs after printing the line
"
" calcoo-1.3.16/src/aux.c
"
" This happens on two different i386 systems, both running an up to date Cygwin
" on an up to date Windows XP with
Dear list,
I've been using Cygwin daily for years and I'm very happy with it.
But today it threw a nice puzzle at me. I must confess I became
a list member just to report it.
My Cygwin /usr/bin/tar hangs when unpacking an archive:
curl ftp://ftp.debian.org/debian/pool/main/c/calcoo/calcoo_1
On Nov 26 15:38, Matthias Andree wrote:
> Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
> :
>
> >Hi folks,
> >
> >
> >I just uploaded a new Cygwin 1.7 test release, 1.7.0-66.
> >
> >If this doesn't introduce any new regressions, this will (probably)
> >be the last test release.
>
> Greetings
Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
:
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-66.
If this doesn't introduce any new regressions, this will (probably)
be the last test release.
Greetings,
after having played with Cygwin 1.5 on XP SP3 for a long while,
Corinna Vinschen wrote:
> On Nov 26 10:35, Corinna Vinschen wrote:
>> However, Chuck, can you please try the below patch to run.c instead?
>> It makes the stdout and stderr handles already distinct in run:
I can't reproduce the problem with the original run (my xterm dumps
core, for a different re
I'm having some serious slowness issues with Cygwin (1.7) on my Windows 7
x64 machine. Background research told me to test things with strace, and
I've noticed that every strace so far gives me major slowness on two
consecutive lines, e.g.:
$ strace ls
[...]
512680 [main] ls 3404 time: 1259
On Nov 26 10:35, Corinna Vinschen wrote:
> However, Chuck, can you please try the below patch to run.c instead?
> It makes the stdout and stderr handles already distinct in run:
>
> Index: src/run.c
> ===
> RCS file: /cvs/cygwin-apps/
On Nov 25 23:44, Charles Wilson wrote:
> Yaakov (Cygwin/X) wrote:
> > I came across this error with run when launched from the cmd prompt with
> > an empty CYGWIN variable:
> >
> > 1 [main] xterm 1248 dtable::stdio_init: couldn't make stderr
> > distinct from stdout
> >
> > If I set CYGWIN=t
20 matches
Mail list logo
