* Process map and fork problems @ 2016-04-20 10:38 Achim Gratz 2016-04-20 10:46 ` Achim Gratz 2016-04-20 10:50 ` Corinna Vinschen 0 siblings, 2 replies; 17+ messages in thread From: Achim Gratz @ 2016-04-20 10:38 UTC (permalink / raw) To: cygwin I'm chasing a problem on some 32bit Windows installs that supposedly happened after one of the Windows updates (and probably other software updates) in the last few months (the affected users were unable to pin it down further unfortunately). It's obviously caused by two heap sections in the process map that are smack dab in the middle of the address range used by rebase: 20000000-200A0000 rw-p 00000000 0000:0000 0 [heap] 200A0000-38000000 ===p 000A0000 0000:0000 0 [heap] These do not exist on 32bit Cygwin installs on 64bit Windows installations, so I couldn't see these problems on my test machine. If I rebase the colliding DLL manually out of this region, things start to work again. Is there any way to find out where these come from? The address range seems to be fixed so far, so I probably could have rebase skip this range, but I'd rather move these out of the way if possible. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 10:38 Process map and fork problems Achim Gratz @ 2016-04-20 10:46 ` Achim Gratz 2016-04-20 10:50 ` Corinna Vinschen 1 sibling, 0 replies; 17+ messages in thread From: Achim Gratz @ 2016-04-20 10:46 UTC (permalink / raw) To: cygwin Achim Gratz <Stromeko <at> NexGo.DE> writes: > I'm chasing a problem on some 32bit Windows installs that supposedly > happened after one of the Windows updates (and probably other software > updates) in the last few months (the affected users were unable to pin it > down further unfortunately). It's obviously caused by two heap sections in > the process map that are smack dab in the middle of the address range used > by rebase: > > 20000000-200A0000 rw-p 00000000 0000:0000 0 [heap] > 200A0000-38000000 ===p 000A0000 0000:0000 0 [heap] > > These do not exist on 32bit Cygwin installs on 64bit Windows installations, > so I couldn't see these problems on my test machine. On the 64bit Windows installations two eerily similar heap sections appear much higher in the process image: 80000000-80070000 rw-p 00000000 0000:0000 0 [heap] 80070000-98000000 ===p 00070000 0000:0000 0 [heap] Hm.... why would something like that move from 2GB down to 0.5GB? Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 10:38 Process map and fork problems Achim Gratz 2016-04-20 10:46 ` Achim Gratz @ 2016-04-20 10:50 ` Corinna Vinschen 2016-04-20 11:01 ` Corinna Vinschen 2016-04-20 11:14 ` Achim Gratz 1 sibling, 2 replies; 17+ messages in thread From: Corinna Vinschen @ 2016-04-20 10:50 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1639 bytes --] Hi Achim, On Apr 20 10:27, Achim Gratz wrote: > I'm chasing a problem on some 32bit Windows installs that supposedly > happened after one of the Windows updates (and probably other software > updates) in the last few months (the affected users were unable to pin it > down further unfortunately). It's obviously caused by two heap sections in > the process map that are smack dab in the middle of the address range used > by rebase: > > 20000000-200A0000 rw-p 00000000 0000:0000 0 [heap] > 200A0000-38000000 ===p 000A0000 0000:0000 0 [heap] This is one heap. The first region is just the already committed part, the remainder is the reserved part. THis is the standard Cygwin heap area on 32 bit machines, which always starts at 0x20000000. > These do not exist on 32bit Cygwin installs on 64bit Windows installations, On 64 bit systems, 32 bit applications have a 4 Gig virtual address space. On 32 bit systems, procecces only have a 2 Gig virtual address space, unless the /3gb kernel option is given. On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit Cygwin processes always starts at 0x80000000L. Since that isn't available on 32 bit systems by default, the heap has to start within the lower 2 Gigs. That's where the 0x2000000 address comes from. If you have collisions because you're providing too many Cygwin DLLs, you have to tweak these installations manually. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 10:50 ` Corinna Vinschen @ 2016-04-20 11:01 ` Corinna Vinschen 2016-04-20 11:14 ` Achim Gratz 1 sibling, 0 replies; 17+ messages in thread From: Corinna Vinschen @ 2016-04-20 11:01 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2054 bytes --] On Apr 20 12:46, Corinna Vinschen wrote: > Hi Achim, > > On Apr 20 10:27, Achim Gratz wrote: > > I'm chasing a problem on some 32bit Windows installs that supposedly > > happened after one of the Windows updates (and probably other software > > updates) in the last few months (the affected users were unable to pin it > > down further unfortunately). It's obviously caused by two heap sections in > > the process map that are smack dab in the middle of the address range used > > by rebase: > > > > 20000000-200A0000 rw-p 00000000 0000:0000 0 [heap] > > 200A0000-38000000 ===p 000A0000 0000:0000 0 [heap] > > This is one heap. The first region is just the already committed > part, the remainder is the reserved part. > > THis is the standard Cygwin heap area on 32 bit machines, which always > starts at 0x20000000. > > > These do not exist on 32bit Cygwin installs on 64bit Windows installations, > > On 64 bit systems, 32 bit applications have a 4 Gig virtual address > space. On 32 bit systems, procecces only have a 2 Gig virtual address > space, unless the /3gb kernel option is given. > > On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit > Cygwin processes always starts at 0x80000000L. > > Since that isn't available on 32 bit systems by default, the heap has > to start within the lower 2 Gigs. That's where the 0x2000000 address > comes from. > > If you have collisions because you're providing too many Cygwin DLLs, > you have to tweak these installations manually. We could also move the heap address for default 32 bit systems to 0x30000000 or 0x40000000 or whatever is more convenient. However, every memory area has its own problems in the tight 32 bit address space. We shouldn't do this without more testing. Alternatively, kick out the 32 bit systems ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 10:50 ` Corinna Vinschen 2016-04-20 11:01 ` Corinna Vinschen @ 2016-04-20 11:14 ` Achim Gratz 2016-04-20 11:15 ` Corinna Vinschen 2016-04-20 13:06 ` Marco Atzeri 1 sibling, 2 replies; 17+ messages in thread From: Achim Gratz @ 2016-04-20 11:14 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > This is one heap. The first region is just the already committed > part, the remainder is the reserved part. > > THis is the standard Cygwin heap area on 32 bit machines, which always > starts at 0x20000000. So, shouldn't rebase keep this area clear on these machines? > On 64 bit systems, 32 bit applications have a 4 Gig virtual address > space. On 32 bit systems, procecces only have a 2 Gig virtual address > space, unless the /3gb kernel option is given. OK. On Windows7 that means 'BCDedit /set increaseuserva=3072', right? I think all the affected machines have 4GB memory installed, but the option may not have been default when they were installed. > On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit > Cygwin processes always starts at 0x80000000L. > > Since that isn't available on 32 bit systems by default, the heap has > to start within the lower 2 Gigs. That's where the 0x2000000 address > comes from. With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE? > If you have collisions because you're providing too many Cygwin DLLs, > you have to tweak these installations manually. As long as Cygwin determines automatically where the heap is located, then rebase should take care of that. It already knows to skip the cygwin1.dll address range, how would it ask for the heap location? No I don't think I have an overly large Cygwin installation, but Perl, Octave and Python pull in a lot of images. I guess what pushed it over the edge is the LLVM stuff that something pulls in since a few months, so that explains the timeframe of the problem popping up most probably. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 11:14 ` Achim Gratz @ 2016-04-20 11:15 ` Corinna Vinschen 2016-04-20 11:56 ` Achim Gratz 2016-04-20 13:06 ` Marco Atzeri 1 sibling, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2016-04-20 11:15 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2404 bytes --] On Apr 20 11:01, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > This is one heap. The first region is just the already committed > > part, the remainder is the reserved part. > > > > THis is the standard Cygwin heap area on 32 bit machines, which always > > starts at 0x20000000. > > So, shouldn't rebase keep this area clear on these machines? > > > On 64 bit systems, 32 bit applications have a 4 Gig virtual address > > space. On 32 bit systems, procecces only have a 2 Gig virtual address > > space, unless the /3gb kernel option is given. > > OK. On Windows7 that means 'BCDedit /set increaseuserva=3072', right? Yeah, I think so. /3gb is the old XP way to define it. > I think all the affected machines have 4GB memory installed, but the > option may not have been default when they were installed. They never are default. Default is 2 Gigs application VM, 2 Gigs kernel̇ memory space. Specifying /3Gb means 3 Gigs application VM vs. 1 Gig kernel̇ memory space. That's not always a good thing since it could lead to kernel memory pool exhaustion. > > On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit > > Cygwin processes always starts at 0x80000000L. > > > > Since that isn't available on 32 bit systems by default, the heap has > > to start within the lower 2 Gigs. That's where the 0x2000000 address > > comes from. > > With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE? No, PAE works differently, using different calls. I'm talking abut the normal 32 bit address space of a 32 bit CPU. > > If you have collisions because you're providing too many Cygwin DLLs, > > you have to tweak these installations manually. > > As long as Cygwin determines automatically where the heap is located, then > rebase should take care of that. It already knows to skip the cygwin1.dll > address range, how would it ask for the heap location? It can only know its own heap. But keep in mind that the heap can be differently sized in different applications. The heap only *starts* as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...) when calling sbrk. Patches welcome, of course. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 11:15 ` Corinna Vinschen @ 2016-04-20 11:56 ` Achim Gratz 2016-04-20 14:20 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2016-04-20 11:56 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > I think all the affected machines have 4GB memory installed, but the > > option may not have been default when they were installed. > > They never are default. Default is 2 Gigs application VM, 2 Gigs > kernel̇ memory space. Specifying /3Gb means 3 Gigs application VM > vs. 1 Gig kernel̇ memory space. That's not always a good thing > since it could lead to kernel memory pool exhaustion. I meant "not default in the base install image provided by corporate IT". I'll have to ask if they have some special procedure to switch it on. > > With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE? > > No, PAE works differently, using different calls. I'm talking abut > the normal 32 bit address space of a 32 bit CPU. Hmm. Microsoft's 4GT documentation makes you believe that /3GB and PAE is always coupled, though. But then even non-/3GB might laready use some PAE facilities anyway. But I guess it's not important. > It can only know its own heap. But keep in mind that the heap can > be differently sized in different applications. The heap only *starts* > as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...) > when calling sbrk. So it can grow only so much until it runs into the first loaded DLL above? Or does it fragment into yet unused areas then? Regards, Achim. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 11:56 ` Achim Gratz @ 2016-04-20 14:20 ` Corinna Vinschen 2016-04-20 14:40 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2016-04-20 14:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1840 bytes --] On Apr 20 11:24, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > > I think all the affected machines have 4GB memory installed, but the > > > option may not have been default when they were installed. > > > > They never are default. Default is 2 Gigs application VM, 2 Gigs > > kernel̇ memory space. Specifying /3Gb means 3 Gigs application VM > > vs. 1 Gig kernel̇ memory space. That's not always a good thing > > since it could lead to kernel memory pool exhaustion. > > I meant "not default in the base install image provided by corporate IT". > I'll have to ask if they have some special procedure to switch it on. > > > > With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE? > > > > No, PAE works differently, using different calls. I'm talking abut > > the normal 32 bit address space of a 32 bit CPU. > > Hmm. Microsoft's 4GT documentation makes you believe that /3GB and PAE is > always coupled, though. But then even non-/3GB might laready use some PAE > facilities anyway. But I guess it's not important. > > > It can only know its own heap. But keep in mind that the heap can > > be differently sized in different applications. The heap only *starts* > > as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...) > > when calling sbrk. > > So it can grow only so much until it runs into the first loaded DLL above? > Or does it fragment into yet unused areas then? It can't fragment, it can only grow. The Unix heap management doesn't have the notion of multiple application heaps. There's only the sbrk call to raise or shrink the size of the heap. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 14:20 ` Corinna Vinschen @ 2016-04-20 14:40 ` Achim Gratz 2016-04-20 14:52 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2016-04-20 14:40 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > It can't fragment, it can only grow. The Unix heap management doesn't > have the notion of multiple application heaps. There's only the sbrk > call to raise or shrink the size of the heap. Thanks for the confirmation. It looks like I am allowed to migrate the machines to a 3GB VM, thus circumventing the heap collision with DLL. Meanwhile I've looked at some problems that typically happen when loading emacs-x11 and it turns out that this loads a number of Windows DLL related to the display drivers and some others related to networking to low addresses. The only way I see to get around that is to try to enable ASLR, so what's the latest on doing that with Cygwin DLL? As far as I understand we should then rebase from 0x50000000 down since the range above is used by ASLR for any DLL that we still need top load to fixed addresses? Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 14:40 ` Achim Gratz @ 2016-04-20 14:52 ` Corinna Vinschen 2016-04-20 15:01 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2016-04-20 14:52 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1175 bytes --] On Apr 20 14:29, Achim Gratz wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > It can't fragment, it can only grow. The Unix heap management doesn't > > have the notion of multiple application heaps. There's only the sbrk > > call to raise or shrink the size of the heap. > > Thanks for the confirmation. It looks like I am allowed to migrate the > machines to a 3GB VM, thus circumventing the heap collision with DLL. > Meanwhile I've looked at some problems that typically happen when loading > emacs-x11 and it turns out that this loads a number of Windows DLL related > to the display drivers and some others related to networking to low > addresses. The only way I see to get around that is to try to enable ASLR, > so what's the latest on doing that with Cygwin DLL? As far as I understand > we should then rebase from 0x50000000 down since the range above is used by > ASLR for any DLL that we still need top load to fixed addresses? ASLR is toxic to fork... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 14:52 ` Corinna Vinschen @ 2016-04-20 15:01 ` Achim Gratz 0 siblings, 0 replies; 17+ messages in thread From: Achim Gratz @ 2016-04-20 15:01 UTC (permalink / raw) To: cygwin Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > ASLR is toxic to fork... Well, that was the reason for the '--noaslr' switch in rebaselst, which can be activated by the peflags argument to rebase-trigger. However, in the case of emacs-x11 I've just tested ASLR allowed it to work through what would otherwise have been a fork-abort, so it might help to relieve some pressure on the adress space layout. I don't think it's a good idea to try adding the libraries in the Windows system directory to the rebase map and I have even less ideas on how to prevent Windows from putting it's own DLL in the "rebase space" when X11 starts up... Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 11:14 ` Achim Gratz 2016-04-20 11:15 ` Corinna Vinschen @ 2016-04-20 13:06 ` Marco Atzeri 2016-04-22 12:12 ` Achim Gratz 1 sibling, 1 reply; 17+ messages in thread From: Marco Atzeri @ 2016-04-20 13:06 UTC (permalink / raw) To: cygwin On 20/04/2016 13:01, Achim Gratz wrote: > > No I don't think I have an overly large Cygwin installation, but Perl, > Octave and Python pull in a lot of images. I guess what pushed it over the > edge is the LLVM stuff that something pulls in since a few months, so that > explains the timeframe of the problem popping up most probably. Noted the same, after some cleaning I have currently all the space taken between: /usr/libexec/coreutils/libstdbuf.so base 0x07650000 .. /usr/bin/BugpointPasses.dll base 0x6fff0000 Octave is a good chuck, but not the only one > > Regards, > Achim. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-20 13:06 ` Marco Atzeri @ 2016-04-22 12:12 ` Achim Gratz 2016-04-22 12:41 ` Marco Atzeri 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2016-04-22 12:12 UTC (permalink / raw) To: cygwin Marco Atzeri <marco.atzeri <at> gmail.com> writes: > Octave is a good chuck, but not the only one That gave me an idea... actually, Octave collectively is taking up about 60% of the address space on my installation. Or rather octave-forge is and more specifically just one package: octave-tisean. So I guess I should blacklist that since I don't think anybody around here uses it. I'm not sure why these dynamic modules are as large as they are, but they are by far the largest ones in the whole install, followed distantly by the netcdf DLL. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-22 12:12 ` Achim Gratz @ 2016-04-22 12:41 ` Marco Atzeri 2016-04-22 13:23 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Marco Atzeri @ 2016-04-22 12:41 UTC (permalink / raw) To: cygwin On 22/04/2016 13:58, Achim Gratz wrote: > Marco Atzeri <marco.atzeri <at> gmail.com> writes: >> Octave is a good chuck, but not the only one > > That gave me an idea... actually, Octave collectively is taking up about 60% > of the address space on my installation. Or rather octave-forge is and more > specifically just one package: octave-tisean. So I guess I should blacklist > that since I don't think anybody around here uses it. I'm not sure why > these dynamic modules are as large as they are, but they are by far the > largest ones in the whole install, followed distantly by the netcdf DLL. > > > Regards, > Achim. > the dll's are small $ cd /usr/lib/octave/packages/tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/ $ du -hs 1.6M . but clearly, there is something wrong in them: $ rebase -si | awk '{print $5, $1}' |sort ... 0x01038000 /usr/bin/cygoctinterp-3.dll 0x0104f000 /usr/bin/cygoctave-3.dll 0x0123a000 /usr/bin/cyggcj-16.dll 0x0126e000 /usr/bin/cyggcj-15.dll 0x012ad000 /usr/bin/cygLLVM-3.5.dll 0x017ed000 /usr/bin/cygicudata56.dll 0x01834000 /usr/bin/cygicudata54.dll 0x01885000 /usr/bin/cygicudata57.dll 0x01f98000 /usr/bin/cygQt5WebKit-5.dll 0x03126000 /usr/bin/cygnetcdf-11.dll 0x0cb25000 /usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__surrogates__.oct 0x0cb25000 /usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__upo__.oct 0x0cb25000 /usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/lazy.oct 0x0cb26000 /usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__c1__.oct I will investigate. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-22 12:41 ` Marco Atzeri @ 2016-04-22 13:23 ` Achim Gratz 2016-04-22 14:20 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2016-04-22 13:23 UTC (permalink / raw) To: cygwin Marco Atzeri <marco.atzeri <at> gmail.com> writes: > the dll's are small > > $ cd /usr/lib/octave/packages/tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/ > > $ du -hs > 1.6M . > > but clearly, there is something wrong in them: Static data? The bss segment is taking up much space... $ objdump -h tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/__surrogates__.oct tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/__surrogates__.oct: file format pei-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 000154e0 00000003ca061000 00000003ca061000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 000001f8 00000003ca077000 00000003ca077000 00015a00 2**6 CONTENTS, ALLOC, LOAD, DATA 2 .rdata 0000190c 00000003ca078000 00000003ca078000 00015c00 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 00000035 00000003ca07a000 00000003ca07a000 00017600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata 000005ac 00000003ca07b000 00000003ca07b000 00017800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .xdata 00000bd4 00000003ca07c000 00000003ca07c000 00017e00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 0cb050f0 00000003ca07d000 00000003ca07d000 00000000 2**6 ALLOC 7 .edata 00000e8e 00000003d6b83000 00000003d6b83000 00018a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .idata 00000fb4 00000003d6b84000 00000003d6b84000 00019a00 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .reloc 000000b8 00000003d6b85000 00000003d6b85000 0001aa00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-22 13:23 ` Achim Gratz @ 2016-04-22 14:20 ` Achim Gratz 2016-04-22 17:41 ` Marco Atzeri 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2016-04-22 14:20 UTC (permalink / raw) To: cygwin Achim Gratz <Stromeko <at> NexGo.DE> writes: > Static data? The bss segment is taking up much space... Yup, the F77 parts apparently use COMMON arrays "the sizes are chosen generously for normal purposes". Ugh. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Process map and fork problems 2016-04-22 14:20 ` Achim Gratz @ 2016-04-22 17:41 ` Marco Atzeri 0 siblings, 0 replies; 17+ messages in thread From: Marco Atzeri @ 2016-04-22 17:41 UTC (permalink / raw) To: cygwin On 22/04/2016 15:23, Achim Gratz wrote: > Achim Gratz <Stromeko <at> NexGo.DE> writes: >> Static data? The bss segment is taking up much space... > > Yup, the F77 parts apparently use COMMON arrays "the sizes are chosen > generously for normal purposes". Ugh. > > > Regards, > Achim. > > I opened a ticket upstream https://savannah.gnu.org/bugs/index.php?47761 As it is reusing a third library I do not expect a fast correction. I will report also on netcdf the same issue. Thanks Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-04-22 14:40 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-20 10:38 Process map and fork problems Achim Gratz 2016-04-20 10:46 ` Achim Gratz 2016-04-20 10:50 ` Corinna Vinschen 2016-04-20 11:01 ` Corinna Vinschen 2016-04-20 11:14 ` Achim Gratz 2016-04-20 11:15 ` Corinna Vinschen 2016-04-20 11:56 ` Achim Gratz 2016-04-20 14:20 ` Corinna Vinschen 2016-04-20 14:40 ` Achim Gratz 2016-04-20 14:52 ` Corinna Vinschen 2016-04-20 15:01 ` Achim Gratz 2016-04-20 13:06 ` Marco Atzeri 2016-04-22 12:12 ` Achim Gratz 2016-04-22 12:41 ` Marco Atzeri 2016-04-22 13:23 ` Achim Gratz 2016-04-22 14:20 ` Achim Gratz 2016-04-22 17:41 ` Marco Atzeri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).