On 8/10/2011 10:56 AM, Ken Brown wrote:
On 8/9/2011 10:39 PM, Ryan Johnson wrote:
Given that the static heap is only 12MB, with most of that arguably
occupied by stuff that isn't going away, what if we did "just ignore the
static heap" (mostly)? Anything freed from that regionjust gets dropped
o
On Aug 10 11:58, Eliot Moss wrote:
> On 8/10/2011 11:28 AM, Ken Brown wrote:
>
> >Would it be possible to accomplish the same goal without using bss_sbrk and
> >the static heap? In
> >other words, can one save the information on the Cygwin heap as part of
> >emacs.exe, so that when
> >emacs is r
On 8/10/2011 11:28 AM, Ken Brown wrote:
Would it be possible to accomplish the same goal without using bss_sbrk and the
static heap? In
other words, can one save the information on the Cygwin heap as part of
emacs.exe, so that when
emacs is run the heap gets restored? I know virtually nothing
On 8/10/2011 7:47 AM, Corinna Vinschen wrote:
On Aug 9 22:33, Ken Brown wrote:
On 8/9/2011 2:21 PM, Ken Brown wrote:
BTW, I don't necessarily have to use the malloc that comes with
emacs. I just verified that I can build emacs so that it uses
Cygwin's malloc. I haven't done any testing yet to
On 8/9/2011 10:39 PM, Ryan Johnson wrote:
On 09/08/2011 10:33 PM, Ken Brown wrote:
I submitted a bug report and may or may not get a useful response.
While waiting, I'd like to keep trying to figure out what the right
fix is. Unless the dumping mechanism (unexec) is completely revamped,
we can'
On Aug 9 22:33, Ken Brown wrote:
> On 8/9/2011 2:21 PM, Ken Brown wrote:
> BTW, I don't necessarily have to use the malloc that comes with
> emacs. I just verified that I can build emacs so that it uses
> Cygwin's malloc. I haven't done any testing yet to make sure there
> are no glitches, but I
On 09/08/2011 10:33 PM, Ken Brown wrote:
On 8/9/2011 2:21 PM, Ken Brown wrote:
On 8/9/2011 11:21 AM, Corinna Vinschen wrote:
However, whatever you do, it will not really work. Keep in mind that
the large address awareness only makes sense (and has any effect!) on
systems which provide a large
On 8/9/2011 2:21 PM, Ken Brown wrote:
On 8/9/2011 11:21 AM, Corinna Vinschen wrote:
However, whatever you do, it will not really work. Keep in mind that
the large address awareness only makes sense (and has any effect!) on
systems which provide a large address area.
To me the bottom line here
On 8/9/2011 12:20 PM, Ryan Johnson wrote:
I'm pretty sure emacs [thinks it] doesn't even use the system heaps
(sort of how cygwin doesn't use the windows heaps); from what I
remember, the "heap" in [t]emacs is an .idata section of the image (12MB
large on my version of emacs) which is supposed to
On 8/9/2011 11:21 AM, Corinna Vinschen wrote:
On Aug 9 10:23, Ken Brown wrote:
On 8/9/2011 10:12 AM, Ken Brown wrote:
On 8/9/2011 7:19 AM, Ken Brown wrote:
(gdb) thread 1
[Switching to thread 1 (Thread 19828.0x447c)]
#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
703
On 09/08/2011 11:21 AM, Corinna Vinschen wrote:
On Aug 9 10:23, Ken Brown wrote:
On 8/9/2011 10:12 AM, Ken Brown wrote:
On 8/9/2011 7:19 AM, Ken Brown wrote:
(gdb) thread 1
[Switching to thread 1 (Thread 19828.0x447c)]
#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
703
On Aug 9 10:23, Ken Brown wrote:
> On 8/9/2011 10:12 AM, Ken Brown wrote:
> >On 8/9/2011 7:19 AM, Ken Brown wrote:
> >>(gdb) thread 1
> >>[Switching to thread 1 (Thread 19828.0x447c)]
> >>#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
> >>703 while ((__malloc_size_t) B
On 8/9/2011 10:12 AM, Ken Brown wrote:
On 8/9/2011 7:19 AM, Ken Brown wrote:
(gdb) thread 1
[Switching to thread 1 (Thread 19828.0x447c)]
#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
703 while ((__malloc_size_t) BLOCK ((char *) result + size)>
newsize);
(gdb) p /x
On 8/9/2011 7:19 AM, Ken Brown wrote:
(gdb) thread 1
[Switching to thread 1 (Thread 19828.0x447c)]
#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
703 while ((__malloc_size_t) BLOCK ((char *) result + size)>
newsize);
(gdb) p /x size
$1 = 0x101000
(gdb) p /x heapsize
$
On 8/9/2011 7:19 AM, Ken Brown wrote:
(gdb) thread 1
[Switching to thread 1 (Thread 19828.0x447c)]
#0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
703 while ((__malloc_size_t) BLOCK ((char *) result + size) > newsize);
(gdb) p /x size
$1 = 0x101000
(gdb) p /x heapsize
$2 = 0x8000
On 8/9/2011 4:26 AM, Corinna Vinschen wrote:
On Aug 8 19:07, Eliot Moss wrote:
On 8/8/2011 5:17 PM, Ken Brown wrote:
do
newsize *= 2;
while ((__malloc_size_t) BLOCK ((char *) result + size)> newsize);
My guess now is that there was some invalid pointer arithmetic somewhere that
led to this
On Aug 8 19:07, Eliot Moss wrote:
> On 8/8/2011 5:17 PM, Ken Brown wrote:
>
> >do
> >newsize *= 2;
> >while ((__malloc_size_t) BLOCK ((char *) result + size) > newsize);
> >
> >My guess now is that there was some invalid pointer arithmetic somewhere
> >that led to this, but I
> >don't have time
On 8/8/2011 5:17 PM, Ken Brown wrote:
do
newsize *= 2;
while ((__malloc_size_t) BLOCK ((char *) result + size) > newsize);
My guess now is that there was some invalid pointer arithmetic somewhere that
led to this, but I
don't have time at the moment to look for it. I'll do it later (or tomorro
On 8/8/2011 4:16 PM, Ken Brown wrote:
On 8/8/2011 2:20 PM, Achim Gratz wrote:
Corinna Vinschen<...> writes:
still tries to workaround some old problem in the Cygwin sbrk
implementation in Cygwin 1.5. Unfortunately the comment doesn't contain
any hint as to what exact problem this code is try
On 8/8/2011 2:20 PM, Achim Gratz wrote:
Corinna Vinschen<...> writes:
still tries to workaround some old problem in the Cygwin sbrk
implementation in Cygwin 1.5. Unfortunately the comment doesn't contain
any hint as to what exact problem this code is trying to workaround.
Apologies if that's
Corinna Vinschen <...> writes:
> still tries to workaround some old problem in the Cygwin sbrk
> implementation in Cygwin 1.5. Unfortunately the comment doesn't contain
> any hint as to what exact problem this code is trying to workaround.
Apologies if that's obvious and you've already checked th
On Aug 8 12:05, Ken Brown wrote:
> On 8/8/2011 11:50 AM, Corinna Vinschen wrote:
> >On Aug 8 09:22, Ken Brown wrote:
> >>I attached gdb to the running process and got some more information.
> >>It turns out that this has nothing to do with X. It's just that
> >>starting emacs under X causes emac
On 8/8/2011 11:50 AM, Corinna Vinschen wrote:
On Aug 8 09:22, Ken Brown wrote:
I attached gdb to the running process and got some more information.
It turns out that this has nothing to do with X. It's just that
starting emacs under X causes emacs to try to allocate memory, and
this makes the
On Aug 8 09:22, Ken Brown wrote:
> I attached gdb to the running process and got some more information.
> It turns out that this has nothing to do with X. It's just that
> starting emacs under X causes emacs to try to allocate memory, and
> this makes the problem show up very quickly.
>
> It loo
On Aug 7 18:38, Ken Brown wrote:
> On 8/7/2011 4:02 PM, Corinna Vinschen wrote:
> >What I did now is to change Cygwin to return always RLIM_INFINITY in
> >a call to getrlimit(RLIMIT_AS). This seems to be more correct anyway,
> >given the definition in SUSv4(*):
> >
> > "If a call to getrlimit()
On 8/7/2011 6:38 PM, Ken Brown wrote:
I've built cygwin1.dll from the latest CVS and confirmed that the
problem is fixed. Unfortunately, I've just discovered a second problem,
also starting with the 2011-07-21 snapshot, that only shows up when I
try to start emacs under X (with emacs large addre
On 8/7/2011 4:02 PM, Corinna Vinschen wrote:
On Aug 7 12:18, Ken Brown wrote:
On 8/7/2011 10:43 AM, Ken Brown wrote:
On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
I did set breakpoints to all functions returning malloc information,
but emacs doesn't call one of them. Is there a chance that em
On 8/7/2011 4:02 PM, Corinna Vinschen wrote:
On Aug 7 12:18, Ken Brown wrote:
On 8/7/2011 10:43 AM, Ken Brown wrote:
On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
I did set breakpoints to all functions returning malloc information,
but emacs doesn't call one of them. Is there a chance that em
On Aug 7 12:18, Ken Brown wrote:
> On 8/7/2011 10:43 AM, Ken Brown wrote:
> >On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
> >>>I did set breakpoints to all functions returning malloc information,
> >>>but emacs doesn't call one of them. Is there a chance that emacs
> >>>does some invalid 32 bit p
On 8/7/2011 10:43 AM, Ken Brown wrote:
On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
On Aug 7 13:33, Corinna Vinschen wrote:
On Aug 5 19:16, Ken Brown wrote:
Starting with the 2011-07-21 snapshot, emacs doesn't work well with
the large-address-awareness flag set (under 64-bit Win7). As soon
On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
On Aug 7 13:33, Corinna Vinschen wrote:
On Aug 5 19:16, Ken Brown wrote:
Starting with the 2011-07-21 snapshot, emacs doesn't work well with
the large-address-awareness flag set (under 64-bit Win7). As soon
as emacs is started, a *Warning* buffer
On Aug 7 13:33, Corinna Vinschen wrote:
> On Aug 5 19:16, Ken Brown wrote:
> > Starting with the 2011-07-21 snapshot, emacs doesn't work well with
> > the large-address-awareness flag set (under 64-bit Win7). As soon
> > as emacs is started, a *Warning* buffer is created with the
> > following m
On Aug 5 19:16, Ken Brown wrote:
> Starting with the 2011-07-21 snapshot, emacs doesn't work well with
> the large-address-awareness flag set (under 64-bit Win7). As soon
> as emacs is started, a *Warning* buffer is created with the
> following message:
>
> Emergency (alloc): Warning: past 95%
33 matches
Mail list logo
