On 22/04/2016 15:23, Achim Gratz wrote:
Achim Gratz 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://s
Achim Gratz 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:
Marco Atzeri 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/x
On 22/04/2016 13:58, Achim Gratz wrote:
Marco Atzeri 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
Marco Atzeri 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 shou
Corinna Vinschen 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 otherw
On Apr 20 14:29, Achim Gratz wrote:
> Corinna Vinschen 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 conf
Corinna Vinschen 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
On Apr 20 11:24, Achim Gratz wrote:
> Corinna Vinschen 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
> > kern
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 prob
Corinna Vinschen 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
On Apr 20 11:01, Achim Gratz wrote:
> Corinna Vinschen 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 0x2000.
>
Corinna Vinschen 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 0x2000.
So, shouldn't rebase keep this area clear on the
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 w
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).
Achim Gratz 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 c
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 proce
17 matches
Mail list logo
