Re: CVS 1.7.0 heap errors

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 17 14:54, Brian Ford wrote:
> > > On Wed, 27 Jun 2007, Corinna Vinschen wrote:
> I attained the following output from the attached patch:
> 
>       7 [main] ? (4876) heap_init: baseAddr:  0x680000
>     171 [main] ? (4876) heap_init: allocBase: 0x670000
>     347 [main] ? (4876) heap_init: allocProt: 0x20
>     425 [main] ? (4876) heap_init: regionSize:0xA7000
>     502 [main] ? (4876) heap_init: state:     0x1000
>     614 [main] ? (4876) heap_init: protect:   0x20
>     693 [main] ? (4876) heap_init: type:      0x40000
>     778 [main] ? (4876) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x680000, top 0x6B0000, reserve_size 192512, allocsize 196608, page_const 4096
> 
> I know this isn't much to go on, but just in case...

Nothing to see...

> >, and perhaps why.
> 
> I really wish I had more than a few minutes a week to spend on this :-(.
> Perhaps then I'll be able to figure it out.
> 
> > You could also try to eliminate any change from
> > http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html which is not
> > related to your problem, so that only the exact change causing it is
> > highlighted.  That might give us an idea, hopefully.
> 
> You don't have any suggestions for how to best separate the patch into
> pieces do you?

Look into the ChangeLog for the patch.  It can be divided into two
different changes:

- Changing the cygheap->shared_prefix handling.

  Affects cygheap.cc, fhandler_fifo.cc, posix_ipc.cc, shared.cc,
  thread.cc, wincap.cc and wincap.h.

  The changes to wincap.* are definitely non-critical.  Also, hazarding
  a wild guess, I assume that make (and none of the subsequent
  processes) use FIFOs and POSIX IPC, so you can ignore the changes in
  fhandler_fifo.cc and posix_ipc.cc.

- Changing the way the user privileges are set at process startup.

  Affects dcrt0.cc, sec_helper.cc and security.h.

  Stupidly glaring at this change, I'm wondering if this is the culprit.
  The change itself looks quite harmless.  But the non-obvious result
  is that already very early in the process initialization functions from
  advapi32 are called.  OTOH, Cygwin is load-time linked against advapi32.
  So that shouldn't have any negative effect.  Hmm.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/