unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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: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

* 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
  2011-07-10  0:26   ` Glenn Morris
@ 2011-07-10  0:42     ` Lennart Borgman
  0 siblings, 0 replies; 7+ messages in thread
From: Lennart Borgman @ 2011-07-10  0:42 UTC (permalink / raw)
  To: 3422, rgm; +Cc: 3422-done

On Sun, Jul 10, 2011 at 02:26, Glenn Morris <rgm@gnu.org> wrote:
>
> I don't see that anything can be done with the information in this report.

No. This was just sent for information.





^ 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).