Re: CVS 1.7.0 heap errors
On Jul 18 12:04, Corinna Vinschen wrote: On Jul 17 14:54, Brian Ford wrote: On Wed, 27 Jun 2007, Corinna Vinschen wrote: 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, [...] 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. [...] - 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. I found an actual bug in this patch. I moved the call to set_cygwin_privileges (hProcToken); at process initialization to a point at which hProcToken wasn't even initialized. *hitting myself with a big stick* Weird that it worked at all. This *might* be the cause of the failing heap_init. The problem is that the calls to AdjustTokenPrivileges in set_privilege fail and debug_printf is called (too?) early in process initialization, which in turn results in dynamically loading user32.dll or some other Windows DLL. If this happens before the heap is initialized, there's a chance that the Windows DLL reserves space which is needed for the heap. What you could do to verify this: Apply the patch from http://cygwin.com/ml/cygwin-cvs/2007-q3/msg00039.html to Cygwin from right after the patch from http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html and try if the heap problem still occurs. 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/
Re: CVS 1.7.0 heap errors
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: 0x68 171 [main] ? (4876) heap_init: allocBase: 0x67 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: 0x4 778 [main] ? (4876) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, 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/
Re: CVS 1.7.0 heap errors
On Wed, 27 Jun 2007, Corinna Vinschen wrote:
On Jun 27 09:22, Brian Ford wrote:
On Wed, 27 Jun 2007, Corinna Vinschen wrote:
On Jun 22 12:16, Brian Ford wrote:
On Wed, 6 Jun 2007, Brian Ford wrote:
6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error -
couldn't
allocate heap, Win32 error 487, base 0x68, top 0x6B,
reserve_size
192512, allocsize 196608, page_const 4096
585603 [main] make 1736 fork: child -1 - died waiting for longjmp
before
initialization, retry 0, exit code 0x100, errno 11
[...]
I'm pretty sure I've identified the change, but I don't see any
obvious cause. Corinna, do you have any suggestions about where
to target or how to specifically dig deeper? Thanks.
http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html
I can't reproduce this problem on XP,
Or, did you try if setting the heap_slop_in_mb registry value to some
different value (default 0 up to XP, 4 since 2K3) helps?
I'll give it a try, but I guess I'd like to find out what the conflict is.
Any tips on how to catch this in the debugger or if inserting some sort of
vitual query would be informative?
Not really, except for the obvious. Try to find out what already uses
the address area which is used as heap in the parent
I attained the following output from the attached patch:
7 [main] ? (4876) heap_init: baseAddr: 0x68
171 [main] ? (4876) heap_init: allocBase: 0x67
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: 0x4
778 [main] ? (4876) C:\cygwin\bin\make.exe: *** fatal error - couldn't
allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size
192512, allocsize 196608, page_const 4096
I know this isn't much to go on, but just in case...
, 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?
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...Index: heap.cc
===
RCS file: /cvs/src/src/winsup/cygwin/heap.cc,v
retrieving revision 1.54
diff -u -p -r1.54 heap.cc
--- heap.cc 31 Oct 2006 18:41:16 - 1.54
+++ heap.cc 17 Jul 2007 19:47:36 -
@@ -94,10 +94,30 @@ heap_init ()
break;
}
if (!p in_forkee !fork_info-handle_failure (GetLastError ()))
+{
+char *end, *addr;
+
+for (addr = (char *)cygheap-user_heap.base, end = addr + reserve_size; addr
end; )
+{
+MEMORY_BASIC_INFORMATIONinfo;
+if ( VirtualQuery(addr, info, sizeof(info)))
+{
+ system_printf(baseAddr: 0x%x\n, info.BaseAddress);
+ system_printf(allocBase: 0x%x\n, info.AllocationBase);
+ system_printf(allocProt: 0x%x\n, info.AllocationProtect);
+ system_printf(regionSize:0x%x\n, info.RegionSize);
+ system_printf(state: 0x%x\n, info.State);
+ system_printf(protect: 0x%x\n, info.Protect);
+ system_printf(type: 0x%x\n, info.Type);
+ addr = (char *)info.BaseAddress + info.RegionSize;
+}
+else break;
+}
api_fatal (couldn't allocate heap, %E, base %p, top %p,
reserve_size %d, allocsize %d, page_const %d,
cygheap-user_heap.base, cygheap-user_heap.top,
reserve_size, allocsize, page_const);
+}
if (p != cygheap-user_heap.base)
api_fatal (heap allocated at wrong address %p (mapped) != %p
(expected), p, cygheap-user_heap.base);
if (allocsize !VirtualAlloc (cygheap-user_heap.base, allocsize,
MEM_COMMIT, PAGE_READWRITE))
--
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/
Re: CVS 1.7.0 heap errors
On Jun 22 12:16, Brian Ford wrote: On Wed, 6 Jun 2007, Brian Ford wrote: FYI, I'm seeing the following errors quite often with current 1.7.0 CVS and have been for some time. For instance, I can't use my CVS build to build Cygwin again. I've yet to have time to investigate much, and don't see that changing for some time :-(. 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 This is just in case any developer remembers a recent (within a couple of months) possibly related change. If not, I'll try to binary search CVS as soon as my schedule frees up some. Thanks. I'm pretty sure I've identified the change, but I don't see any obvious cause. Corinna, do you have any suggestions about where to target or how to specifically dig deeper? Thanks. http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html I can't reproduce this problem on XP, nor do I see anything in this change which might cause this. Rebasing? Or, did you try if setting the heap_slop_in_mb registry value to some different value (default 0 up to XP, 4 since 2K3) helps? 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/
Re: CVS 1.7.0 heap errors
On Wed, 27 Jun 2007, Corinna Vinschen wrote: On Jun 22 12:16, Brian Ford wrote: On Wed, 6 Jun 2007, Brian Ford wrote: FYI, I'm seeing the following errors quite often with current 1.7.0 CVS and have been for some time. For instance, I can't use my CVS build to build Cygwin again. I've yet to have time to investigate much, and don't see that changing for some time :-(. 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 This is just in case any developer remembers a recent (within a couple of months) possibly related change. If not, I'll try to binary search CVS as soon as my schedule frees up some. Thanks. I'm pretty sure I've identified the change, but I don't see any obvious cause. Corinna, do you have any suggestions about where to target or how to specifically dig deeper? Thanks. http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html I can't reproduce this problem on XP, Any chance you could try it with a /3gb appended to your boot.ini and reboot; just in case? nor do I see anything in this change which might cause this. Neither did I, but rolling forward and back several times confirms that this is strongly correlated to my problem. Rebasing? Tried several times :-(. Or, did you try if setting the heap_slop_in_mb registry value to some different value (default 0 up to XP, 4 since 2K3) helps? I'll give it a try, but I guess I'd like to find out what the conflict is. Any tips on how to catch this in the debugger or if inserting some sort of vitual query would be informative? Thanks for your help. -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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/
Re: CVS 1.7.0 heap errors
On Jun 27 09:22, Brian Ford wrote: On Wed, 27 Jun 2007, Corinna Vinschen wrote: On Jun 22 12:16, Brian Ford wrote: On Wed, 6 Jun 2007, Brian Ford wrote: 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 [...] I'm pretty sure I've identified the change, but I don't see any obvious cause. Corinna, do you have any suggestions about where to target or how to specifically dig deeper? Thanks. http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html I can't reproduce this problem on XP, Any chance you could try it with a /3gb appended to your boot.ini and reboot; just in case? Done. I can't reproduce this problem with /3GB either, sorry. Or, did you try if setting the heap_slop_in_mb registry value to some different value (default 0 up to XP, 4 since 2K3) helps? I'll give it a try, but I guess I'd like to find out what the conflict is. Any tips on how to catch this in the debugger or if inserting some sort of vitual query would be informative? Not really, except for the obvious. Try to find out what already uses the address area which is used as heap in the parent, and perhaps why. 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. 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/
Re: CVS 1.7.0 heap errors
On Wed, 6 Jun 2007, Brian Ford wrote: FYI, I'm seeing the following errors quite often with current 1.7.0 CVS and have been for some time. For instance, I can't use my CVS build to build Cygwin again. I've yet to have time to investigate much, and don't see that changing for some time :-(. 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 This is just in case any developer remembers a recent (within a couple of months) possibly related change. If not, I'll try to binary search CVS as soon as my schedule frees up some. Thanks. I'm pretty sure I've identified the change, but I don't see any obvious cause. Corinna, do you have any suggestions about where to target or how to specifically dig deeper? Thanks. http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00139.html -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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/
CVS 1.7.0 heap errors
FYI, I'm seeing the following errors quite often with current 1.7.0 CVS and have been for some time. For instance, I can't use my CVS build to build Cygwin again. I've yet to have time to investigate much, and don't see that changing for some time :-(. 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 This is just in case any developer remembers a recent (within a couple of months) possibly related change. If not, I'll try to binary search CVS as soon as my schedule frees up some. Thanks. -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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/
