bug#3422: 23.0.94; window-height returns window buffer

bug#3422: 23.0.94; window-height returns window buffer

[Lennart Borgman]

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'

bug#3422: 23.0.94; window-height returns window buffer

[Eli Zaretskii]

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

bug#3422: 23.0.94; window-height returns window buffer

[Lennart Borgman]

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

bug#3422: 23.0.94; window-height returns window buffer

[Glenn Morris]

I don't see that anything can be done with the information in this report.

bug#3422: 23.0.94; window-height returns window buffer

[Lennart Borgman]

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.

bug#3422: 23.0.94; window-height returns window buffer

[Jason Rumney]

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?

bug#3422: 23.0.94; window-height returns window buffer

[Lennart Borgman]

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