Digging a little further ...
The conflicting dll was /bin/cygpng16-16.dll.
rebase display it with a * indicating that there was a space conflict
for it. So I did a rebase-trigger full and ran setup again. Now
these two dlls share the same spot:
/usr/bin/cygp11-kit-0.dll
/usr/lib/p11-kit-proxy
On 7/9/2023 12:55 PM, Eliot Moss wrote:
On 7/9/2023 11:56 AM, Ken Brown via Cygwin wrote:
On 7/8/2023 9:37 PM, Eliot Moss via Cygwin wrote:
Dear cygwin-ers --
I'm running 64-bit cygwin 3.4.7-1 and lately I've been getting these
vfork
errors from emacs-gtk when I try to run dired on a director
On 7/9/2023 11:56 AM, Ken Brown via Cygwin wrote:
On 7/8/2023 9:37 PM, Eliot Moss via Cygwin wrote:
Dear cygwin-ers --
I'm running 64-bit cygwin 3.4.7-1 and lately I've been getting these vfork
errors from emacs-gtk when I try to run dired on a directory. I believe this
tries to fork ls to get
On 7/8/2023 9:37 PM, Eliot Moss via Cygwin wrote:
Dear cygwin-ers --
I'm running 64-bit cygwin 3.4.7-1 and lately I've been getting these vfork
errors from emacs-gtk when I try to run dired on a directory. I believe
this
tries to fork ls to get the necessary file information. I've tried
upda
On 7/17/2022 12:35 PM, Brian Inglis wrote:
On 2022-07-17 08:15, Ken Brown wrote:
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
On 2022-07-17 08:15, Ken Brown wrote:
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
Please see the release announcement:
https
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
Please see the release announcement:
https://cygwin.com/pipermail/cygwin-announce
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
If I switch to 28.1-1 the problem disappears. When I go back to 28.1-2
it reappears 100%.
I did "rebaseall".
I have Soph
On Thu, 13 Feb 2020 22:42:31 +0100
Peter Dons Tychsen wrote:
> On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote:
> > Could you please try latest snapshot?
> > https://cygwin.com/snapshots/
>
> The commit regarding use of kill() does the trick.
> It's a go from here :-).
>
> Thanks for all th
Hi Takashi,
On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote:
> Could you please try latest snapshot?
> https://cygwin.com/snapshots/
The commit regarding use of kill() does the trick.
It's a go from here :-).
Thanks for all the help,
/pedro
--
Problem reports: http://cygwin.com/pr
On Wed, 12 Feb 2020 11:54:02 +0100
Peter Dons Tychsen wrote:
> Hi Takashi,
>
> On Wed, 2020-02-12 at 11:24 +0900, Takashi Yano wrote:
> > My failure in pty code was that I used kill() in pty system
> > calls. kill() can be used check if the process is still alive
> > by passing signal number of 0
On Tue, 11 Feb 2020 09:21:32 -0500
Ken Brown wrote:
> On 2/11/2020 8:16 AM, Takashi Yano wrote:
> > On Tue, 11 Feb 2020 11:38:35 +0100
> > Peter Dons Tychsen wrote:
> >> On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> >>> Is this the same as your problem?
> >>
> >> Yeah, it could be. Could
On Feb 12 11:24, Takashi Yano wrote:
> On Tue, 11 Feb 2020 22:31:12 +0100
> Peter Dons Tychsen wrote:
> > On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> > > however, I found the real cause is that errno is accidentally set
> > > by kill() in pty system calls. That is, the problem is not i
On Tue, 11 Feb 2020 22:31:12 +0100
Peter Dons Tychsen wrote:
> On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> > however, I found the real cause is that errno is accidentally set
> > by kill() in pty system calls. That is, the problem is not in the
> > kill() itself but in usage of it. Cyg
Hi Takashi,
Thanks for your effort.
On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> however, I found the real cause is that errno is accidentally set
> by kill() in pty system calls. That is, the problem is not in the
> kill() itself but in usage of it. Cygwin older than 3.1.0 does not
>
On 2/11/2020 8:16 AM, Takashi Yano wrote:
On Tue, 11 Feb 2020 11:38:35 +0100
Peter Dons Tychsen wrote:
On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
Is this the same as your problem?
Yeah, it could be. Could this result in fork error messages as we are
seeing all over the place?
No
On Tue, 11 Feb 2020 11:38:35 +0100
Peter Dons Tychsen wrote:
> On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> > Is this the same as your problem?
>
> Yeah, it could be. Could this result in fork error messages as we are
> seeing all over the place?
No. Fork error is not seen in my envir
On Tue, 2020-02-11 at 11:38 +0100, Peter Dons Tychsen wrote:
> processes. And why did this work before?
And why does it work when running without minnty? How does that play
into this?
Thanks,
/pedro
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.
Hi Takashi,
Thanks for looking at this & your great work on Cygwin!
On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> Is this the same as your problem?
Yeah, it could be. Could this result in fork error messages as we are
seeing all over the place?
> If so, it goes without stopping 1 min
On Mon, 10 Feb 2020 21:58:09 +0100
Peter Dons Tychsen wrote:
> 1) Put attached makefile somewhere
> 2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe
> and unzip it in same place.
> 3) Now run "make create"
> 4) Now run "make clean && make -j32". Try a couple of times.
>
> -
On 11/02/2020 07:58, Peter Dons Tychsen wrote:
It seems to be related to the fact the is is spawning non-cygwin
programs. If i do the same test with normal GCC (default cygwin gcc)
then everything is fine.
That's great work, and I can confirm that it is the same in my
environment. Our makefile
Hi all,
On Thu, 2020-02-06 at 09:18 +1100, David Finnie wrote:
> That would be awesome if you could create a small test case
OK, i put together a test-case:
1) Put attached makefile somewhere
2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe
and unzip it in same place.
3) Now
On 8/02/2020 05:13, Brian Inglis wrote:
DF's post immediately preceding that KB post at the start of*January* *was*
Brian, indeed. And, as I'm sure you're aware - given that you were
trawling through past posts - Ken already pulled me up on it, and since
then I haven't. It has been my *only*
On 2020-02-05 16:35, Ken Brown wrote:
> On 2/5/2020 6:07 PM, David Finnie wrote:
>>> [Please don't top-post on this list. Thanks.]
>> What do you mean by top posting, then ? How was my post a top post ?
> It wasn't. I misread it. Sorry.
DF's post immediately preceding that KB post at the start
On Wed, 5 Feb 2020 17:07:38 -0500
Ken Brown wrote:
> That last issue is probably due to changes in
> /usr/bin/cygwin-console-helper.exe
> related to the new PTY code. So in addition to rewinding the DLL, you have
> to
> rewind cygwin-console-helper.
Indeed, cygwin-console-helper.exe was chang
On 2/5/2020 6:07 PM, David Finnie wrote:
[Please don't top-post on this list. Thanks.]
What do you mean by top posting, then ? How was my post a top post ?
It wasn't. I misread it. Sorry.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwi
[Please don't top-post on this list. Thanks.]
What do you mean by top posting, then ? How was my post a top post ?
Thanks.
Dave
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsu
[Please don't top-post on this list. Thanks.]
On 2/5/2020 5:18 PM, David Finnie wrote:
Hi Pedro,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
Unfortunat
Hi Pedro,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
Unfortunately no, I did get a clean build, but "make install" following
it just created complete ha
On 2/5/2020 4:45 PM, Peter Dons Tychsen wrote:
Hi David & Co,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
I have found something interesting:
1) If i r
Hi David & Co,
> I have started down the road of building cygwin, but did run into a
> few issues so don't have a debuggable version yet. If you beat me to
> it, please let me know. Thanks!
Any findings?
I have found something interesting:
1) If i run the terminal without mintty, the problem g
[Please don't top-post on this list. Thanks.]
On 1/2/2020 5:29 PM, David Finnie wrote:
> Hi Pedro,
>
> That's good to hear confirmation.
>
> I have started down the road of building cygwin, but did run into a few
> issues so don't have a debuggable version yet. If you beat me to it,
> please le
Hi Pedro,
That's good to hear confirmation.
I have started down the road of building cygwin, but did run into a few
issues so don't have a debuggable version yet. If you beat me to it,
please let me know. Thanks!
Dave
On Fri, 3 Jan. 2020, 08:58 Peter Dons Tychsen, wrote:
> Hi Cygwinners,
>
>
Hi Cygwinners,
On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote:
> I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)
>
> That has fixed the issue for me, and the make it now running again
> at
> full speed. I forgot to mention that it did seem somewhat slower
> with
> the new
ay wait forever, or deliver an orphan SIGCHILD. */
> if (!child.reattach ())
> {
> this_errno = EAGAIN;
> #ifdef DEBUGGING0
> error ("child reattach failed");
> #endif
> goto cleanup;
> }
>
> Since I am getting "R
DEBUGGING0
error ("child reattach failed");
#endif
goto cleanup;
}
Since I am getting "Resource temporarily unavailable", which equates to
EAGAIN, and this code is new, this looks like the most likely candidate
to investigate first (but rest assured that I'm n
) specified, some of the sub-makes fail with "Resource
temporarily unavailable" errors. In all cases, this has been when make is
starting a shell (i.e. $(shell ...) ) to help with setting up some of the
variables required in the make processing. The failure, however, occurs in
different pla
../build/Make/platform_options.mk:9: fork: Resource temporarily
> unavailable
> make[2]: ../../build/Make/platform_options_linux.mk:33: fork: Resource
> temporarily unavailable
> make[2]: ../../build/Make/platform_options.mk:9: fork: Resource temporarily
> unavailable
> make[2]: ../../b
I recently upgraded my cygwin64 installation to get latest packages.
After the install, if I run a fairly lengthy GNU make with multiple
concurrent jobs (-j option) specified, some of the sub-makes fail with
"Resource temporarily unavailable" errors. In all cases, this has been
wh
mpted when I `git clone` any repository,
>>
>>0 [main] git-remote-https 24312 child_info_fork::abort:
>> C:\cygwin\bin\cygcurl-4.dll: Loaded to different address:
>> parent(0x580000) != child(0xCC0000)
>> error: cannot fork() for fetch-pack: Resource temporarily unavai
different address:
parent(0x58) != child(0xCC)
error: cannot fork() for fetch-pack: Resource temporarily unavailable
You need to do a full rebase (and possibly reboot) to fix this. If you're not
sure how to do a full rebase, see the following recent thread:
https://www.cygwin.c
) != child(0xCC)
error: cannot fork() for fetch-pack: Resource temporarily unavailable
With the `cygcheck git`, it showed a few api-ms-win-* missed, e.g.
$ cygcheck git
cygcheck: track_down: could not find api-ms-win-core-rtlsupport-l1-2-0.dll
cygcheck: track_down: could not find api-ms-win
Rockefeller, Harry writes:
> Instructions above state running setup-x86.exe not setup-x86_64.exe.
> Does anyone experience frequent emacs vfork errors running 64-bit Cygwin?
> Maybe it's time for me to try running that again?
DLL collisions are _much_ less likely on x86_64 out of the gate, but
the
Re: BLODA
This is what worked for me over the weekend. I use Microsoft Security
Essentials, no other anti-virus/malware/etc. software:
- in MSE, disable real-time checking
- reboot
- trigger full rebaseall
- run Cygwin setup
- in MSIE, re-enable real-time checking
I have not had any problems si
>To: cygwin@cygwin.com
>Subject: Re: Doing vfork: resource temporarily unavailable
>
>"Rockefeller, Harry" writes:
>
>>>-Original Message-
>>>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
>>>Behalf Of Jim Reisert
"Rockefeller, Harry" writes:
>>-Original Message-
>>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
>>Jim Reisert AD1C
>>Sent: Wednesday, May 20, 2015 8:54 AM
>>To: cygwin@cygwin.com
>>Subject: Re: Doing vfork
Sebastien Vauban writes:
> 1 [main] emacs-w32 235400 child_info_fork::abort:
> C:\cygwin\bin\cyggs-9.dll: Loaded to different address: parent(0x171) !=
> child(0x19E)
> 2 [main] emacs-w32 235352 child_info_fork::abort:
> C:\cygwin\bin\cyggs-9.dll: Loaded to different address:
On Wed, May 20, 2015 at 8:13 AM, Rockefeller, Harry wrote:
> Recently I spent about an hour running numerous rebaseall commands
> interspersed with
> at least one rerun of setup-x86 and 3 reboots before my emacs vfork errors
> went away.
> I don't know if it was the third reboot or something els
>-Original Message-
>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
>Jim Reisert AD1C
>Sent: Wednesday, May 20, 2015 8:54 AM
>To: cygwin@cygwin.com
>Subject: Re: Doing vfork: resource temporarily unavailable
>
>> This indicates
> This indicates that you need to run a full rebase
> (https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures). The
> simplest way to do this is to run '/usr/bin/rebase-trigger full', then stop
> all Cygwin processes and services, and then run setup-x86.exe. The
> _autorebase postinstall
On 5/20/2015 6:08 AM, Sebastien Vauban wrote:
Hello,
When launching Cygwin Emacs 24.5 [1] with my standard `.emacs' file
(which I successfully use with Windows Emacs 24.5 and 25.0), I have
"Doing vfork: resource temporarily unavailable" errors.
[...]
1 [main]
Hello,
When launching Cygwin Emacs 24.5 [1] with my standard `.emacs' file
(which I successfully use with Windows Emacs 24.5 and 25.0), I have
"Doing vfork: resource temporarily unavailable" errors.
I had to disable the following block of code to allow Cygwin Emacs to go
to
On Mar 8 16:11, Ulf-Dietrich Braumann wrote:
> I guess, when I was installing the service before, I may have
> changed something in the Properties menu of the CYGWIN sshd service,
> perhaps I tested something under the SYSTEM account and then have
> reverted to the cyg_server account, so by this a
Thanks, Corinna, for asking if sshd was called with the -D option. This
was the point, although I do not really know why -D was missing (I used
ssh-host-config).
This is was came out before (sshd in fact was running):
$ cygrunsrv -Q sshd
Service : sshd
Display name: CYGWIN
On Mar 8 11:21, Ulf-Dietrich Braumann wrote:
> Well, while sshd now can be launched again by cygrunsrv, still the
> mechanism behaves weird, in the event viewer sshd tells me to be
> stopped short after it was started,
That doesn't happen for me. Does your service entry for sshd omit
the -D opti
Well, while sshd now can be launched again by cygrunsrv, still the
mechanism behaves weird, in the event viewer sshd tells me to be stopped
short after it was started, however in fact it runs. And in the services
list the "Started" entry is missing, so it cannot be stopped there. - What
counts
Great, Corinna, now cygrunsrv in its new version 1.40-1 works on my Win2k3
64bit machine. Thanks for the repair - Ulf-Dietrich
On Wed, 7 Mar 2012, Corinna Vinschen wrote:
I just released a new cygrunsrv which fixes the problem for me. What it
does is to fork in a separate pthread, for which t
On Mar 5 18:39, Corinna Vinschen wrote:
> On Mar 5 12:33, Charles Wilson wrote:
> > On 3/5/2012 11:31 AM, Corinna Vinschen wrote:
> > > Why this only fails when cygrunsrv has been built with gcc-4 but not with
> > > gcc-3 is most puzzeling.
> >
> > $ cygcheck /usr/bin/cygrunsrv.exe
> > C:\cygwin
On Mar 5 12:33, Charles Wilson wrote:
> On 3/5/2012 11:31 AM, Corinna Vinschen wrote:
> > Why this only fails when cygrunsrv has been built with gcc-4 but not with
> > gcc-3 is most puzzeling.
>
> $ cygcheck /usr/bin/cygrunsrv.exe
> C:\cygwin\bin\cygrunsrv.exe
> C:\cygwin\bin\cygwin1.dll
>
On 3/5/2012 11:31 AM, Corinna Vinschen wrote:
> Why this only fails when cygrunsrv has been built with gcc-4 but not with
> gcc-3 is most puzzeling.
$ cygcheck /usr/bin/cygrunsrv.exe
C:\cygwin\bin\cygrunsrv.exe
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\syste
On Mar 4 15:53, Ulf-Dietrich Braumann wrote:
> Yes, Corinna, I reverted this setting again to the default 384MB
> heap size calling:
>
> $ peflags --cygwin-heap=0 /usr/sbin/sshd.exe
> and
> $ peflags --cygwin-heap=0 /usr/bin/cygrunsrv.exe
>
> Later on, someone has recommended me to downgrade cyg
Ulf-Dietrich Braumann wrote:
> Yes, Corinna, I reverted this setting again to the default 384MB heap size
> calling:
>
> $ peflags --cygwin-heap=0 /usr/sbin/sshd.exe
> and
> $ peflags --cygwin-heap=0 /usr/bin/cygrunsrv.exe
>
> Later on, someone has recommended me to downgrade cygrunsrv from 1.3
Yes, Corinna, I reverted this setting again to the default 384MB heap size
calling:
$ peflags --cygwin-heap=0 /usr/sbin/sshd.exe
and
$ peflags --cygwin-heap=0 /usr/bin/cygrunsrv.exe
Later on, someone has recommended me to downgrade cygrunsrv from 1.36-1 to
1.34-1. This helped, so now under cyg
On Mar 3 20:16, Ulf-Dietrich Braumann wrote:
> On Sat, 3 Mar 2012, Larry Hall (Cygwin) wrote:
>
> >Try this:
> >http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures
>
> Thanks. Unfortunately, rebaseall did not help. I also tried
> peflagsall and a reboot, but no change. Also, I do
has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.
In the windows event viewer I found
"... starting service `sshd' failed: fork: 11, Resource temporarily
unavailable."
--
Problem reports: http://cygwin.com/problems.html
FAQ:
ted.
A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.
In the windows event viewer I found
"... starting service `sshd' failed: fork: 11, Resource temporarily
unavailable."
Try this:
<http://cygwin.com/faq-nochunks.html#
ror 1067 has occurred.
The process terminated unexpectedly.
In the windows event viewer I found
"... starting service `sshd' failed: fork: 11, Resource temporarily
unavailable."
Inspired by Carl Soderstrom's solution for a similar problem I have tried
a program-individual
I want to make sure my solution ends up in the archives for the benefit of
other people.
> From: "Corinna Vinschen"
> On Feb 9 15:39, Carl Soderstrom wrote:
> > Changing the stack size using regtool (regtool.exe -i set
> > /HKLM/Software/Cygwin/heap_chunk_in_mb 2048) has not fixed the
> > pro
On Feb 9 15:39, Carl Soderstrom wrote:
> Changing the stack size using regtool (regtool.exe -i set
> /HKLM/Software/Cygwin/heap_chunk_in_mb 2048) has not fixed the problem.
I don't know what the problem is here, but please note the change in
terms of the heap size in 1.7.10:
http://cygwin.com/c
On 2/9/2012 10:39 PM, Carl Soderstrom wrote:
Pardon me if this is old news, but searching the mailing lists has not yielded
a solution that solves the problems I'm having on this computer.
system is Windows XP Professional (patched up to date), Cygwin version is:
$ uname -a
CYGWIN_NT-5.1 CADMAN
> From: "Carl Soderstrom"
> Reinstallation (of 1.7.9 and 1.7.10) has not fixed the problem; even
> after completely deleting all of C:\cygwin.
>
> Changing the stack size using regtool (regtool.exe -i set
> /HKLM/Software/Cygwin/heap_chunk_in_mb 2048) has not fixed the
> problem.
>
> I looked a
i686 Cygwin
I can register a service such as rsyncd using cygrunsrv (cygrunsrv -R
), but when I try to start it, the 'error 1062' appears on the command
line and the following error appears in the Application log:
rsyncd: PID 3216: starting service `rsyncd' failed: fork: 11, R
On 8/11/2011 10:02 AM, Heiko Elger wrote:
Christopher Faylor writes:
On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote:
Ryan Johnson writes:
Let me ask again, what was being compiled when the problems arose? And
is it an intermittent error or a consistent one?
I'm sorry - I hav
Christopher Faylor writes:
>
> On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote:
> >Ryan Johnson writes:
> >
> >> Let me ask again, what was being compiled when the problems arose? And
> >> is it an intermittent error or a consistent one?
> >>
> >
> >I'm sorry - I havn't seen your qu
On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote:
>Ryan Johnson writes:
>
>> Let me ask again, what was being compiled when the problems arose? And
>> is it an intermittent error or a consistent one?
>>
>
>I'm sorry - I havn't seen your question.
>
>The error is intermittent.
>Sometime
Ryan Johnson writes:
> Let me ask again, what was being compiled when the problems arose? And
> is it an intermittent error or a consistent one?
>
I'm sorry - I havn't seen your question.
The error is intermittent.
Sometimes I have this error and sometimes not - really not reproduceable.
If it
On 10/08/2011 7:16 AM, Heiko Elger wrote:
Ryan Johnson writes:
Did you reboot? Windows won't notice the changes made by peflagsall
until you do so.
yes
Also, you never mentioned what you are making. Are you, by chance
building an app which builds helper binaries and/or lots of shared
librar
Ryan Johnson writes:
> Did you reboot? Windows won't notice the changes made by peflagsall
> until you do so.
yes
> Also, you never mentioned what you are making. Are you, by chance
> building an app which builds helper binaries and/or lots of shared
> libraries? Apps such as emacs, gcc, an
Heiko Elger writes:
>
> Christopher Faylor writes:
>
> >
> > On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
> > >Hello,
> > >
> > >I know there are lots of such postings "Resource temporarily unavailable"
> > >Bu
On 10/08/2011 7:04 AM, Heiko Elger wrote:
Christopher Faylor writes:
On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
Hello,
I know there are lots of such postings "Resource temporarily unavailable".
But using lates snapshot (2011-08-03): there are changes by C. Faylo
Christopher Faylor writes:
>
> On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
> >Hello,
> >
> >I know there are lots of such postings "Resource temporarily unavailable".
> >But using lates snapshot (2011-08-03): there are changes by C. Fayl
On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
>Hello,
>
>I know there are lots of such postings "Resource temporarily unavailable".
>But using lates snapshot (2011-08-03): there are changes by C. Faylor printing
>cause of fork failure.
I can see I'm
Hello,
I know there are lots of such postings "Resource temporarily unavailable".
But using lates snapshot (2011-08-03): there are changes by C. Faylor printing
cause of fork failure.
I've gotten the following error message while running make in parallel
using (make -j8).
On Thu, Jun 16, 2011 at 01:55:25AM +0300, Ryan Johnson wrote:
>On 15/06/2011 2:14 PM, Kevin Layer wrote:
>> When running make, which spawns shell scripts from time to time, I see
>> this:
>>../../version.sh: fork: retry: Resource temporarily unavailable
>>
>
On 15/06/2011 2:14 PM, Kevin Layer wrote:
When running make, which spawns shell scripts from time to time, I see
this:
../../version.sh: fork: retry: Resource temporarily unavailable
The list archives are full of discussions about this (did you search
them?). The short version is that
version.sh: fork: retry: Resource temporarily unavailable
../../version.sh: fork: retry: Resource temporarily unavailable
../../version.sh: fork: retry: Resource temporarily unavailable
../../version.sh: fork: retry: Resource temporarily unavailable
../../version.sh: fork: Resource t
On 2:59 PM, Ryan Johnson wrote:
I wrote a very simple program whose main() prints out the contents of
/proc/self/maps, forks, calls foo() and bar(), and finally (if the
parent) calls wait().
The trick is, foo() and bar() reside in cygfoo.dll and cygbar.dll
respectively, which I compiled to ha
the dlls gdb complains about?
x7565 is kernel32.dll, but there's no sign of x7719 or x76d2. I tried
nirsoft's 'InjectedDLL' but none of the dlls it finds have those bases,
and windbg doesn't report them either.
2. What determines which of the many bad things
On 2:59 PM, Jon TURNEY wrote:
On 15/03/2011 13:53, Ryan Johnson wrote:
All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
This assumption is due to what?
- Documented Windows feature?
- An observation
On 15/03/2011 13:53, Ryan Johnson wrote:
> All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
> are involved. IOW, consider the case that B depends on A, with A and B both
> conflicting with a later-loade
On 16/03/2011 19:37, Ryan Johnson wrote:
> On 2:59 PM, Henry S. Thompson wrote:
>> Ryan Johnson writes:
>>
>>> BTW, I found a good way to identify, if not fix, BLODA: given an app
>>> which loads no libraries at runtime -- such as 'ls' -- any dlls
>>> mentioned in /proc/$$/maps which cygcheck does
On 2:59 PM, Henry S. Thompson wrote:
Ryan Johnson writes:
BTW, I found a good way to identify, if not fix, BLODA: given an app
which loads no libraries at runtime -- such as 'ls' -- any dlls
mentioned in /proc/$$/maps which cygcheck does not mention are
probably dodgy. In my case, Windows Live
Ryan Johnson writes:
> BTW, I found a good way to identify, if not fix, BLODA: given an app
> which loads no libraries at runtime -- such as 'ls' -- any dlls
> mentioned in /proc/$$/maps which cygcheck does not mention are
> probably dodgy. In my case, Windows Live (which I didn't think was
> even
On 2:59 PM, Jon TURNEY wrote:
On 09/03/2011 17:04, Ryan Johnson wrote
BTW, while looking at the code I noticed a potential source of remap problems:
if B depends on A, and we remap A first, then only A's location will be
checked carefully; B will be pulled in wherever it happens to end up when w
On 07/03/2011 15:10, Ryan Johnson wrote:
> Actually, a follow-up question: what is the difference between the fork(e.g.
> resource unavailable) failures vs. the errors about 'failed to remap dll...'
> ? Looking at the code in dll_init.cc, if failure to remap a dll were really
> the source of fork f
On 2:59 PM, Corinna Vinschen wrote:
On Mar 5 17:15, Ryan Johnson wrote:
Might it be possible to do an LD_PRELOAD of some sort which hooks
into fork() at the critical moment and prints the differences
between /proc/$parent/maps and /proc/$child/maps? The code doesn't
even need to be efficient; i
On Wed, Mar 09, 2011 at 11:22:57AM +0100, Corinna Vinschen wrote:
>Just an idea. Somebody still would have to do it(*).
I've been musing about some ways to make dll handling more robust.
Maybe I'll poke at it for 1.7.10.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Mar 5 17:15, Ryan Johnson wrote:
> Hi all,
>
> I'm hitting the oh-so-delightful fork failures when trying to
> compile a cross-compiler toolchain, which is a pain because one fork
> failure makes crosstool-ng start over. I've rebased, I've been over
> the BLODA (Windows Defender slipped in eve
On 2:59 PM, Ryan Johnson wrote:
I'm hitting the oh-so-delightful fork failures when trying to compile
a cross-compiler toolchain, which is a pain because one fork failure
makes crosstool-ng start over. I've rebased, I've been over the BLODA
(Windows Defender slipped in even after I rejected the
On 2:59 PM, Ryan Johnson wrote:
>
> I'm hitting the oh-so-delightful fork failures when trying
> to compile a cross-compiler toolchain, which is a pain
> because one fork failure makes crosstool-ng start over. I've
> rebased, I've been over the BLODA (Windows Defender slipped
> in even after I rej
1 - 100 of 228 matches
Mail list logo
