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
I occasionally see the following heap allocation problem. This typically
happens when a
bash window has been left idle at its prompt for several hours (eg overnight),
and occurs
on the first command causing an executable to be run. It is independent of the
command
(as far as I can tell - it ha
17 matches
Mail list logo
