unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "J. Scott Berg" <jsberg-bnl@outlook.com>
Cc: 44002@debbugs.gnu.org
Subject: bug#44002: 27.1; Small window height with VcXsrv X server when built with gtk3 toolkit
Date: Fri, 16 Oct 2020 22:08:16 +0300	[thread overview]
Message-ID: <83d01iugyn.fsf@gnu.org> (raw)
In-Reply-To: <MN2PR12MB4606951D68960E1D3AA9DDEC9A030@MN2PR12MB4606.namprd12.prod.outlook.com> (jsberg-bnl@outlook.com)

> From: "J. Scott Berg" <jsberg-bnl@outlook.com>
> Date: Fri, 16 Oct 2020 14:47:46 +0000
> Cc: "44002@debbugs.gnu.org" <44002@debbugs.gnu.org>
> 
> Below I've shown the a the adjust_fram_size breaks. Just before the call with new_width=1280, new_height=1, a full window with the correct size, a menu bar, and otherwise a white background is visible. After that call, the window retains the same size, but below the menu there is a single text line (white) buffer, the status line, and a single text line (white) minibuffer; the remainder of the window below that is black. I showed the backtrace for that call. After the subsequent call, the window size jumps to approximately 5 text lines, keeping the same buffer/status/minibuffer as before, and the last two-ish text lines are black. After the subsequent call, I have an ordinary-looking emacs window except for the fact that the main buffer is only 3 lines long.

Thanks.

> Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=1280, new_height=1, inhibit=5, pretend=false,
>     parameter=0x3c60) at frame.c:597
> 597     {
> (gdb) where
> #0  adjust_frame_size (f=0x555556034200, new_width=1280, new_height=1, inhibit=5, pretend=false, parameter=0x3c60) at frame.c:597
> #1  0x00005555555a9fe3 in change_frame_size_1
>     (pixelwise=<optimized out>, safe=false, delay=false, pretend=false, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at lisp.h:1033
> #2  change_frame_size
>     (pixelwise=<optimized out>, safe=false, delay=false, pretend=false, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at dispnew.c:5830
> #3  do_pending_window_change (safe=safe@entry=false) at dispnew.c:5756
> #4  0x00005555555e275f in message3_nolog (m=<optimized out>) at xdisp.c:11019
> #5  0x00005555555e29e8 in message3 (m=m@entry=0x555555ff32a4) at xdisp.c:10950
> #6  0x00005555556f3d90 in Fmessage (args=0x7fffffffccb0, nargs=<optimized out>) at editfns.c:2891
> #7  Fmessage (nargs=<optimized out>, args=0x7fffffffccb0) at editfns.c:2859
> #8  0x00005555556fcb6b in Ffuncall (nargs=3, args=args@entry=0x7fffffffcca8) at lisp.h:2110
> #9  0x00005555557350c8 in exec_byte_code
>     (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
> #10 0x00005555556fcaa7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd020) at eval.c:2809
> #11 0x00005555557350c8 in exec_byte_code
>     (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
> #12 0x00005555556fcaa7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd828) at eval.c:2809
> #13 0x00005555557350c8 in exec_byte_code
>     (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
> #14 0x00005555556fcaa7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffe1e0) at eval.c:2809
> #15 0x00005555557350c8 in exec_byte_code
>     (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
> #16 0x00005555556ffd3d in apply_lambda (fun=0x7ffff285eb25, args=<optimized out>, count=4) at eval.c:2927
> #17 0x00005555556fedd6 in eval_sub (form=<optimized out>) at eval.c:2349
> #18 0x00005555557008d9 in Feval (form=0x7ffff29bb68b, lexical=<optimized out>) at eval.c:2103
> #19 0x00005555556fbcd7 in internal_condition_case
>     (bfun=bfun@entry=0x555555680ac0 <top_level_2>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x555555686300 <cmd_error>)
>     at eval.c:1356
> #20 0x00005555556819a6 in top_level_1 (ignore=ignore@entry=0x0) at lisp.h:1033
> #21 0x00005555556fbc31 in internal_catch (tag=tag@entry=0xd500, func=func@entry=0x555555681980 <top_level_1>, arg=arg@entry=0x0)
>     at eval.c:1117
> #22 0x0000555555680a48 in command_loop () at lisp.h:1033
> #23 0x0000555555685f16 in recursive_edit_1 () at keyboard.c:714
> #24 0x0000555555686242 in Frecursive_edit () at keyboard.c:786
> #25 0x00005555555a00f7 in main (argc=2, argv=<optimized out>) at emacs.c:2062
> (gdb) c
> Continuing.
> 
> Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=new_width@entry=-1,
>     new_height=new_height@entry=-1, inhibit=inhibit@entry=2, pretend=pretend@entry=false, parameter=parameter@entry=0xd350)
>     at frame.c:597
> 597     {
> (gdb) c
> Continuing.
> 
> Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=1280, new_height=170, inhibit=5, pretend=false,
>     parameter=0x3c60) at frame.c:597
> 597     {
> (gdb) c
> Continuing.

I don't see here any call that makes the frame resize to 5x5, can you
point out which call that is?

Also, please say "where" for each time the breakpoint breaks, and
before that say

  (gdb) source /path/to/emacs/src/.gdbinit

so that "where" also reports Lisp-level backtraces.





  reply	other threads:[~2020-10-16 19:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  1:55 bug#44002: 27.1; Small window height with VcXsrv X server when built with gtk3 toolkit J. Scott Berg
2020-10-16  7:31 ` Eli Zaretskii
2020-10-16 14:47   ` J. Scott Berg
2020-10-16 19:08     ` Eli Zaretskii [this message]
2020-10-16 19:47       ` J. Scott Berg
2020-10-16 23:29         ` J. Scott Berg
2020-10-17  7:52           ` Eli Zaretskii
2020-10-17  9:32             ` martin rudalics
2020-10-17  9:34               ` Eli Zaretskii
2020-10-17  9:40                 ` martin rudalics
2020-10-17 17:32                   ` Eli Zaretskii
2020-10-18 17:52                     ` Robert Pluim
2020-10-18 17:56                       ` Eli Zaretskii
2020-10-19  8:15                         ` Robert Pluim
2021-02-25 20:04                   ` Glenn Morris
2021-02-25 20:28                     ` J. Scott Berg
2021-02-25 20:38                     ` Eli Zaretskii
2020-10-19 14:02               ` J. Scott Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83d01iugyn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=44002@debbugs.gnu.org \
    --cc=jsberg-bnl@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).