Christopher Faylor wrote:
> One scenario that I have seen is that a thread gets started when someone
> hits CTRL-C while a forked process is starting up. Since only one
> thread can execute at a time when a process is in DLL initialization,
> the "other" thread's stack gets allocated but it hangs
Christopher Faylor wrote:
> ...
> One scenario that I have seen is that a thread gets started when someone
> hits CTRL-C while a forked process is starting up. Since only one
> thread can execute at a time when a process is in DLL initialization,
> the "other" thread's stack gets allocated but it
On Jan 18 11:57, Christopher Faylor wrote:
> 1.5.19 may have aggravated this problem since Corinna's changes to mmap
> now use VirtualAlloc'ed space for privately mmapped areas. For some
> inexplicable reason, this causes more of this type of collision. I
> would swear that once a program uses a
On Wed, Jan 18, 2006 at 04:41:08PM -, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Wed, Jan 18, 2006 at 04:18:09PM +, Cliff Hones wrote:
>>> Can this explain failures to initialize executables which don't use
>>> threads? I don't know, but I wouldn't have thought 'ls' uses threads.
>>
Christopher Faylor wrote:
> On Wed, Jan 18, 2006 at 04:18:09PM +, Cliff Hones wrote:
>> Can this explain failures to initialize executables which don't use
>> threads? I don't know, but I wouldn't have thought 'ls' uses threads.
>
> Every cygwin application (and probably every windows applicat
Christopher Faylor wrote:
> Actually, this kind of error is more likely to be caused by a thread
> starting prior to cygwin initialization and grabbing cygwin's heap area
> to use for its stack.
Oh, of course! 2 meg of allocation is going to throw everything wy off!
cheers,
D
Cliff Hones wrote:
>
> Can this explain failures to initialize executables which don't use
> threads? I don't know, but I wouldn't have thought 'ls' uses threads.
*Everything* uses threads, but many apps only use one thread.
cheers,
DaveK
--
Can't think of a witty .sigline today..
On Wed, Jan 18, 2006 at 04:18:09PM +, Cliff Hones wrote:
>Can this explain failures to initialize executables which don't use threads?
>I don't know, but I wouldn't have thought 'ls' uses threads.
Every cygwin application (and probably every windows application) uses
threads. The above scenar
Christopher Faylor wrote:
> On Wed, Jan 18, 2006 at 03:16:27PM -, Dave Korn wrote:
>
>>Cliff Hones wrote:
>>
>>>[main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate
>>>heap, Win32 error 487, base 0x48, top 0x4A, reserve_size 126976,
>>>allocsize 131072, page_co
On Wed, Jan 18, 2006 at 03:16:27PM -, Dave Korn wrote:
>Cliff Hones wrote:
>> [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate
>> heap, Win32 error 487, base 0x48, top 0x4A, reserve_size 126976,
>> allocsize 131072, page_const 4096
>> [main] bash 2160 child_
Dave Korn wrote:
> Cliff Hones wrote:
>>The parent (the bash
>>shell) has been running (and idle) a long time, but the new child which
>>is being forked is presumably a new windows process. The error relates to
>>the virtual mapping in the new process, so Windows appears to be
>>allocating DLLs or
On Jan 18 10:52, Brett Serkez wrote:
> [snip]
> > > I also find the sleep(2000) in heap.cc when the mapping error is
> > > detected rather suspicious - is this to avoid a race condition with
> > > the parent?
> >
> > Dunno, suspect it may have been something experimental. Take a look
> > at wh
[snip]
> > I also find the sleep(2000) in heap.cc when the mapping error is
> > detected rather suspicious - is this to avoid a race condition with
> > the parent?
>
> Dunno, suspect it may have been something experimental. Take a look
> at when it arrived in the CVS and check the associated c
Cliff Hones wrote:
> Dave Korn wrote:
>> (I can see how applications that LoadLibrary a new .dll after they've
>> already been running for a long time and allocated lots of heap might be
>> particularly prone to these remapping failures too).
>
> I'm not sure I understand what you're saying her
Dave Korn wrote:
> Cliff Hones wrote:
>> 6 [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error -
>> couldn't allocate heap, Win32 error 487, base 0x48, top
>>0x4A, reserve_size 126976, allocsize 131072, page_const 4096 98
>>[main] bash 2160 child_copy: stack write c
Cliff Hones wrote:
> 6 [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error -
> couldn't allocate heap, Win32 error 487, base 0x48, top
> 0x4A, reserve_size 126976, allocsize 131072, page_const 4096 98
> [main] bash 2160 child_copy: stack write copy failed, 0x22E9
16 matches
Mail list logo
