* bug#3422: 23.0.94; window-height returns window buffer
@ 2009-05-30 13:20 Lennart Borgman
2009-05-30 13:47 ` Eli Zaretskii
2009-05-30 13:59 ` Jason Rumney
0 siblings, 2 replies; 7+ messages in thread
From: Lennart Borgman @ 2009-05-30 13:20 UTC (permalink / raw
To: emacs-pretest-bug
I do not think I can reproduce this, but (window-height win) just
returned the buffer win was displaying. I can reproduce it now, but I
doubt I can when I have restarted Emacs.
This was with my patched Emacs, but there is no patches in window.c. I
suspect that this has something to do with frame creation since I have
seen many crashes there. Another possibility is w32 resources. I see a
steady increase in GDI Objects in Windows Task Manager and when that
starts to get high very strange things can happen (though it is
perhaps some other resource that is depleted).
After restarting Emacs I still see some problems. I can't use
ediff-revision, I get
Debugger entered--Lisp error: (error "Running cvs -Q update -p
window.c...FAILED (status 255)")
but that may of course be totally unrelated.
In GNU Emacs 23.0.94.1 (i386-mingw-nt5.1.2600)
of 2009-05-23
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#3422: 23.0.94; window-height returns window buffer
2009-05-30 13:20 bug#3422: 23.0.94; window-height returns window buffer Lennart Borgman
@ 2009-05-30 13:47 ` Eli Zaretskii
2009-05-30 13:55 ` Lennart Borgman
2011-07-10 0:26 ` Glenn Morris
2009-05-30 13:59 ` Jason Rumney
1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2009-05-30 13:47 UTC (permalink / raw
To: Lennart Borgman, 3422
> Date: Sat, 30 May 2009 15:20:14 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc:
>
> After restarting Emacs I still see some problems. I can't use
> ediff-revision, I get
>
> Debugger entered--Lisp error: (error "Running cvs -Q update -p
> window.c...FAILED (status 255)")
A full backtrace might be extremely useful here.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#3422: 23.0.94; window-height returns window buffer
2009-05-30 13:47 ` Eli Zaretskii
@ 2009-05-30 13:55 ` Lennart Borgman
2011-07-10 0:26 ` Glenn Morris
1 sibling, 0 replies; 7+ messages in thread
From: Lennart Borgman @ 2009-05-30 13:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 3422
On Sat, May 30, 2009 at 3:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 30 May 2009 15:20:14 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc:
>>
>> After restarting Emacs I still see some problems. I can't use
>> ediff-revision, I get
>>
>> Debugger entered--Lisp error: (error "Running cvs -Q update -p
>> window.c...FAILED (status 255)")
>
> A full backtrace might be extremely useful here.
After rebooting I tested again and it looks like savannah is down so
this is no problem. I was just unsure before rebooting so I included
this too.
However the other problem worries me. As I said it might be related to
frame creation. I have code that creates several frames in a row. I
get no errors, but Emacs has on several occasions crashed later. I did
not see any such crashes until I started using the code which creates
frames. This code is run at Emacs startup just after desktop. It
restores frames and windows. make-frame gets parameters like this
'((icon-name)
(top + -4)
(left + -4)
(unsplittable)
(width . 235)
(height . 64)
(visibility . t)
(modeline . t)
(background-mode . light)
(alpha)
(scroll-bar-width . 17)
(cursor-type . box)
(auto-lower)
(auto-raise)
(icon-type)
(buffer-predicate)
(tool-bar-lines . 0)
(menu-bar-lines . 1)
(right-fringe . 8)
(left-fringe . 8)
(line-spacing)
(screen-gamma)
(border-color . "black")
(cursor-color . "black")
(mouse-color . "black")
(background-color . "SystemWindow")
(foreground-color . "SystemWindowText")
(vertical-scroll-bars . right)
(internal-border-width . 0)
(border-width . 2)
(font . "-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1")
(font-backend uniscribe gdi))
I do not know if this info can help.
I also do some window creation and size modification when restoring
the frames. There could be something in those C routines that are
called there, but I have never seen any crashes when using the same
routines interactively (winsav.el, part of nXhtml).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#3422: 23.0.94; window-height returns window buffer
2009-05-30 13:47 ` Eli Zaretskii
2009-05-30 13:55 ` Lennart Borgman
@ 2011-07-10 0:26 ` Glenn Morris
2011-07-10 0:42 ` Lennart Borgman
1 sibling, 1 reply; 7+ messages in thread
From: Glenn Morris @ 2011-07-10 0:26 UTC (permalink / raw
To: 3422-done
I don't see that anything can be done with the information in this report.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#3422: 23.0.94; window-height returns window buffer
2009-05-30 13:20 bug#3422: 23.0.94; window-height returns window buffer Lennart Borgman
2009-05-30 13:47 ` Eli Zaretskii
@ 2009-05-30 13:59 ` Jason Rumney
2009-05-30 14:07 ` Lennart Borgman
1 sibling, 1 reply; 7+ messages in thread
From: Jason Rumney @ 2009-05-30 13:59 UTC (permalink / raw
To: Lennart Borgman, 3422; +Cc: emacs-pretest-bug
Lennart Borgman wrote:
> I do not think I can reproduce this, but (window-height win) just
> returned the buffer win was displaying. I can reproduce it now, but I
> doubt I can when I have restarted Emacs.
>
Are you saying that memory is corrupted such that the current window's
total_lines member holds a buffer?
> This was with my patched Emacs, but there is no patches in window.c.
It doesn't matter where your patches are if they are causing the memory
corruption.
> I
> suspect that this has something to do with frame creation since I have
> seen many crashes there. Another possibility is w32 resources. I see a
> steady increase in GDI Objects in Windows Task Manager and when that
> starts to get high very strange things can happen (though it is
> perhaps some other resource that is depleted).
>
What are you doing when you see this steady increase? Do you also see it
in the current pretest or CVS trunk?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#3422: 23.0.94; window-height returns window buffer
2009-05-30 13:59 ` Jason Rumney
@ 2009-05-30 14:07 ` Lennart Borgman
0 siblings, 0 replies; 7+ messages in thread
From: Lennart Borgman @ 2009-05-30 14:07 UTC (permalink / raw
To: Jason Rumney; +Cc: emacs-pretest-bug, 3422
On Sat, May 30, 2009 at 3:59 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> I do not think I can reproduce this, but (window-height win) just
>> returned the buffer win was displaying. I can reproduce it now, but I
>> doubt I can when I have restarted Emacs.
>>
>
> Are you saying that memory is corrupted such that the current window's
> total_lines member holds a buffer?
>
>> This was with my patched Emacs, but there is no patches in window.c.
>
> It doesn't matter where your patches are if they are causing the memory
> corruption.
>
>> I
>> suspect that this has something to do with frame creation since I have
>> seen many crashes there. Another possibility is w32 resources. I see a
>> steady increase in GDI Objects in Windows Task Manager and when that
>> starts to get high very strange things can happen (though it is
>> perhaps some other resource that is depleted).
>>
>
> What are you doing when you see this steady increase? Do you also see it in
> the current pretest or CVS trunk?
I do not think this is related to Emacs. It is a bug in xp (and I
think w2k too) in the handling of sticky keys. At each menu invocation
and window switching xp eats gdi objects. I have actually reported
this to ms, but ...
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-07-10 0:42 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-30 13:20 bug#3422: 23.0.94; window-height returns window buffer Lennart Borgman
2009-05-30 13:47 ` Eli Zaretskii
2009-05-30 13:55 ` Lennart Borgman
2011-07-10 0:26 ` Glenn Morris
2011-07-10 0:42 ` Lennart Borgman
2009-05-30 13:59 ` Jason Rumney
2009-05-30 14:07 ` Lennart Borgman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.