>P.S. What to do next? cgf has already received so many gold stars...
I don't need a gold star. Just doing my job Ma'am...He tips his hat and walkes
off into the sunset and the music starts to play.
cgf
--
Problem reports: http://cygwin.com/
>P.S. What to do next? cgf has already received so many gold stars...
I don't need a gold star. Just doing my job...
^ Ma'am
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygw
On Thu, Mar 22, 2012 at 03:37:32PM +0100, Denis Excoffier wrote:
>On Thu, Mar 22, 2012 at 09:29:38AM -0400, Christopher Faylor wrote:
>>> On Thu, Mar 22, 2012@07:56:32AM +0100, Denis Excoffier wrote:
>>> >- in tcsh: several concurrent combinations of 'make -j 3', 'make',
>>> > fg, Control-Z, bg, w
On Thu, Mar 22, 2012 at 09:29:38AM -0400, Christopher Faylor wrote:
>> On Thu, Mar 22, 2012@07:56:32AM +0100, Denis Excoffier wrote:
>> >- in tcsh: several concurrent combinations of 'make -j 3', 'make',
>> > fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)'
>> > and the PC to
On Thu, Mar 22, 2012 at 07:56:32AM +0100, Denis Excoffier wrote:
>- in tcsh: several concurrent combinations of 'make -j 3', 'make',
> fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)'
> and the PC to hang sometimes.
Are you saying that there *is* a problem with the current sn
On Thu, Mar 22, 2012 at 12:38:00AM -0400, Christopher Faylor wrote:
>> On Wed, Mar 21, 2012 at 08:10:46AM +0059, Denis Excoffier wrote:
>> >The snapshot 20120321 05:29:25 UTC has still the following problems:
>>
>> The current snapshot should fix the hang issues.
>>
I'm balancing between reporting
On Wed, Mar 21, 2012 at 08:10:46AM +0059, Denis Excoffier wrote:
>The snapshot 20120321 05:29:25 UTC has still the following problems:
The current snapshot should fix the hang issues.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documenta
On Tue, Mar 20, 2012 at 07:56:19PM -0400, Christopher Faylor wrote:
>> On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote:
>> >On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote:
>> >>[snip]
>> >>Thanks for the cygcheck output.
>> >>
>> >>I was never able to duplicat
On 3/21/2012 5:41 AM, marco atzeri wrote:
On 3/21/2012 12:56 AM, Christopher Faylor wrote:
On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote:
On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote:
[snip]
Thanks for the cygcheck output.
I was never able to duplica
On 3/21/2012 12:56 AM, Christopher Faylor wrote:
On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote:
On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote:
[snip]
Thanks for the cygcheck output.
I was never able to duplicate the problem so I rewrote the way this wa
On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote:
>On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote:
>>[snip]
>>Thanks for the cygcheck output.
>>
>>I was never able to duplicate the problem so I rewrote the way this was
>>handled. The error message is completel
On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote:
>[snip]
>Thanks for the cygcheck output.
>
>I was never able to duplicate the problem so I rewrote the way this was
>handled. The error message is completely gone now.
>
>With luck you won't see anything like this now.
My change
On Fri, Mar 16, 2012 at 01:14:26PM -0400, Christopher Faylor wrote:
>On Fri, Mar 09, 2012 at 10:48:30AM -0500, Christopher Faylor wrote:
>>On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote:
>>>On Mar 8 09:50, Denis Excoffier wrote:
On Wed, Mar 07, 2012 at 06:47:49PM +0100, Cori
On Fri, Mar 09, 2012 at 10:48:30AM -0500, Christopher Faylor wrote:
>On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote:
>>On Mar 8 09:50, Denis Excoffier wrote:
>>> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
>>> >> Hi Denis,
>>> >>
>>> >> can you please test
On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote:
>On Mar 8 09:50, Denis Excoffier wrote:
>> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
>> >> Hi Denis,
>> >>
>> >> can you please test this again using the latest developer snapshot or
>> >> the current from C
On Mar 8 09:50, Denis Excoffier wrote:
> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
> >> Hi Denis,
> >>
> >> can you please test this again using the latest developer snapshot or
> >> the current from CVS if you build Cygwin by yourself? It provides a bit
> >> more informa
On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
>> Hi Denis,
>>
>> can you please test this again using the latest developer snapshot or
>> the current from CVS if you build Cygwin by yourself? It provides a bit
>> more information to find the reason for the permission denied er
Hi Denis,
On Mar 5 13:14, Corinna Vinschen wrote:
> On Mar 5 13:02, Denis Excoffier wrote:
> > On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote:
> > >> On Mar 5 08:09, Denis Excoffier wrote:
> > >> >947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid
> > >> >
On 3/6/2012 2:16 PM, Solomon Foster wrote:
Hi,
Was there ever a resolution to the issue in the subject line? I'm
seeing what looks like a related problem when I try to use cygwin's
svn (installed yesterday). I'm hoping there is a straightforward
solution, because this is a bit of a shop-stoppe
Hi,
Was there ever a resolution to the issue in the subject line? I'm
seeing what looks like a related problem when I try to use cygwin's
svn (installed yesterday). I'm hoping there is a straightforward
solution, because this is a bit of a shop-stopper in my use of
cygwin...
Thanks,
--
Solomon
On Mar 5 13:02, Denis Excoffier wrote:
> On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote:
> >> On Mar 5 08:09, Denis Excoffier wrote:
> >> >947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0:
> >> > res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win
On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote:
>> On Mar 5 08:09, Denis Excoffier wrote:
>> > On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote:
>> > >> Denis, can you please give the latest snapshot DLL a try in all
>> > >> circumstances in which you saw the abov
On Mar 5 08:09, Denis Excoffier wrote:
> On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote:
> >> On Feb 8 11:22, Denis Excoffier wrote:
> >> > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote:
> >> > >> On Feb 8 10:08, Denis Excoffier wrote:
> >> > >> > Result is:
On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote:
>> On Feb 8 11:22, Denis Excoffier wrote:
>> > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote:
>> > >> On Feb 8 10:08, Denis Excoffier wrote:
>> > >> > Result is:
>> > >> >
>> > >> > 1 [main] gcc-4 4084 dll
On Feb 8 14:24, Heiko Elger wrote:
> Corinna Vinschen writes:
>
> >
> > What happens in this testcase is that Cygwin checks the full DLL path
> > and then finds that the new path to cyggcc_s-1.dll is not the same as
> > the path it has already loaded. Therefore it assumes that it has to add
> >
On Feb 8 11:22, Denis Excoffier wrote:
> On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote:
> >> On Feb 8 10:08, Denis Excoffier wrote:
> >> > Result is:
> >> >
> >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed
> >> > by 'cygiconv-2.dll' (0x674C w
On Feb 23 16:25, Richard Gribble wrote:
> Scott M. Ballew purdue.edu> writes:
> > I'm happy to report that after I dropped this new snapshot in place, my
> > original problem has gone away completely (and I've been clean for a few
> > days, now). In fact, it also made it so that I could build some
Scott M. Ballew purdue.edu> writes:
>
>
> Corinna Vinschen-2 wrote:
> >
> >
> > Sigh. While the basename is all we need to test if a DLL is already
> > loaded, it's *not* enough to load a DLL which still needs loading, if
> > the DLLs are not in the DLL search path, as in the case of Perl li
ould build some software
from sources (make and gcc were failing variously with the same type of
error messages). So as of now, I am a very happy camper!
Thanks much!
Scott M. Ballew
Purdue University
--
View this message in context:
http://old.nabble.com/cygwin-1.7.10-1-fork---address-space-n
Greetings, Corinna Vinschen!
> Sigh. While the basename is all we need to test if a DLL is already
> loaded, it's *not* enough to load a DLL which still needs loading,
> if the DLLs are not in the DLL search path, as in the case of Perl libs.
Unless it is registered in
HKLM\SOFTWARE\Microsoft\Wi
On Feb 9 14:37, Denis Excoffier wrote:
> On Thu, Feb 09, 2012 at 12:06:31PM +0100, Corinna Vinschen wrote:
> >> > So it's the same DLL path, just one time with the long pathname prefix
> >> > (or better: The Win32 equivalent to the native NT path prefix). But,
> >> > as I wrote in my mail to Heik
On Thu, Feb 09, 2012 at 02:37:58PM +0059, Denis Excoffier wrote:
>>
>> Usually after installation of a new snapshot i begin with a compilation
>> of the sources. Today the compilation fails in winsup/cygwin/mkimport
>> (perl script) with the following messages:
>> 1 [main] perl 2380 child_in
On Thu, Feb 09, 2012 at 12:06:31PM +0100, Corinna Vinschen wrote:
>> On Feb 8 16:16, Corinna Vinschen wrote:
>> > On Feb 8 15:55, Denis Excoffier wrote:
>> > > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote:
>> > > >> Denis, can you please change your test output? Instead of pr
On Feb 8 16:16, Corinna Vinschen wrote:
> On Feb 8 15:55, Denis Excoffier wrote:
> > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote:
> > >> Denis, can you please change your test output? Instead of printing only
> > >> d_alt->modname, please print d_alt->name and then run your
On Wed, Feb 08, 2012 at 03:05:33PM +, Heiko Elger wrote:
>> Denis Excoffier writes:
>>
>> > Here it is. Enjoy!
>> > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed
>> by 'cygiconv-2.dll' (file
>> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C w
On Feb 8 15:55, Denis Excoffier wrote:
> On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote:
> >> Denis, can you please change your test output? Instead of printing only
> >> d_alt->modname, please print d_alt->name and then run your rsync test
> >> again. If this is the same probl
Denis Excoffier writes:
> Here it is. Enjoy!
> 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed
by 'cygiconv-2.dll' (file
> D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C with
type 1=DLL_LINK)
>1580 [main] gcc-4 5440 dll_list::reserve_space: addr
On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote:
>> On Feb 8 14:00, Corinna Vinschen wrote:
>> > On Feb 8 11:22, Denis Excoffier wrote:
>> > > I can reproduce.
>> > >
>> > > On my system (2012-02-07 snapshot instrumented), the following is able
>> > > to exercise the fork failur
On Feb 8 14:24, Heiko Elger wrote:
> Corinna Vinschen writes:
>
> >
> > What happens in this testcase is that Cygwin checks the full DLL path
> > and then finds that the new path to cyggcc_s-1.dll is not the same as
> > the path it has already loaded. Therefore it assumes that it has to add
> >
Corinna Vinschen writes:
>
> What happens in this testcase is that Cygwin checks the full DLL path
> and then finds that the new path to cyggcc_s-1.dll is not the same as
> the path it has already loaded. Therefore it assumes that it has to add
> the file to list.
>
> This is plainly wrong, bec
On Feb 8 14:00, Corinna Vinschen wrote:
> On Feb 8 11:22, Denis Excoffier wrote:
> > I can reproduce.
> >
> > On my system (2012-02-07 snapshot instrumented), the following is able
> > to exercise the fork failure any time.
> >
> > I do this from within a dedicated directory named "stc".
> > Cu
On Feb 8 11:22, Denis Excoffier wrote:
> I can reproduce.
>
> On my system (2012-02-07 snapshot instrumented), the following is able
> to exercise the fork failure any time.
>
> I do this from within a dedicated directory named "stc".
> Current shell seems indifferent. Here it is /bin/tcsh and
>
On Wed, Feb 8, 2012 at 5:22 AM, Denis Excoffier wrote:
>
> I can reproduce.
>
> On my system (2012-02-07 snapshot instrumented), the following is able
> to exercise the fork failure any time.
>
> I do this from within a dedicated directory named "stc".
> Current shell seems indifferent. Here it is
On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote:
>> On Feb 8 10:08, Denis Excoffier wrote:
>> > Result is:
>> >
>> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by
>> > 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is perhaps already
>> > occupi
On Feb 8 10:08, Denis Excoffier wrote:
> Result is:
>
> 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by
> 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is perhaps already occupied
>1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by
> 'cyg
On Tue, Feb 07, 2012 at 11:48:35PM +0100, Denis Excoffier wrote:
>>
>> On 2012-02-07 17:47, Ryan Johnson wrote:
>> > On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
>> >> On Feb 7 16:43, Denis Excoffier wrote:
>> >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
>> >>> i
On Feb 7 23:48, Denis Excoffier wrote:
> On 2012-02-07 17:47, Ryan Johnson wrote:
> > On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
> >> On Feb 7 16:43, Denis Excoffier wrote:
> >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
> >>> in http://cygwin.com/ml/cygwin/2012
On 2012-02-07 17:47, Ryan Johnson wrote:
> On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
>> On Feb 7 16:43, Denis Excoffier wrote:
>>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
>>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html
>>> [...]
>>> - the /proc//maps
On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
On Feb 7 16:43, Denis Excoffier wrote:
I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
in http://cygwin.com/ml/cygwin/2012-02/msg00092.html
[...]
- the /proc//maps of the processes involved in the fork failure look
normal:
On Feb 7 16:43, Denis Excoffier wrote:
> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html
> [...]
> - the /proc//maps of the processes involved in the fork failure look
> normal:
> ...
> 61262000-6147 rw-p 00262000
On Tue, Feb 07, 2012 at 07:00:25AM -0800, Scott M. Ballew wrote:
>>
>> I've got a Windows XP SP3 (32-bit) system that I just upgraded from Cygwin
>> 1.5 to Cygwin 1.7 as a clean install (deinstalled all old Cygwin, scrubbed
>> the registry, cleared environment variables, etc.) Mostly, it seems to
to no avail.
Thanks,
Scott M. Ballew
Purdue University
--
View this message in context:
http://old.nabble.com/cygwin-1.7.10-1-fork---address-space-needed-by-...-already-in-use-tp33279157p33279157.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: h
52 matches
Mail list logo
