Process map and fork problems

Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Corinna Vinschen]

[-- 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 --]

Re: Process map and fork problems

[Corinna Vinschen]

[-- 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 --]

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Corinna Vinschen]

[-- 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 --]

Re: Process map and fork problems

[Achim Gratz]

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.

Re: Process map and fork problems

[Marco Atzeri]

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

Re: Process map and fork problems

[Corinna Vinschen]

[-- 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 --]

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Corinna Vinschen]

[-- 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 --]

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Marco Atzeri]

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

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Achim Gratz]

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

Re: Process map and fork problems

[Marco Atzeri]

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