all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
To: 49959@debbugs.gnu.org
Subject: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 29 Aug 2021 11:05:14 +0900	[thread overview]
Message-ID: <877dg580px.wl-nomiya@galaxy.dti.ne.jp> (raw)
In-Reply-To: <bb2698b1-0f95-b661-f40a-8cb8dad20807@gmx.at>

Hello,

Sorry for late reply.

I's a hard work for me. :-)

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <bb2698b1-0f95-b661-f40a-8cb8dad20807@gmx.at>
  Date & Time: Thu, 26 Aug 2021 09:52:54 +0200

[RM] == martin rudalics <rudalics@gmx.at> has written:

MN> > 1. for the emacs with bug

MN> > Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x1654540>
MN> > set_window_configuration (4), MS=140x150 IH IV

MN> > 2. for the emacs without bug
MN> >
MN> > Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x25c2540>
MN> > x_make_frame_visible
MN> > set_window_configuration (4), MS=140x150 IH IV

RM>  One interesting aspect is that apparently in neither case we are
RM>  notified that our frame gets hidden when switching desktops.

RM>  Please do the following:

RM>  - Try again with the latest patch I sent you.

RM>  - Send me a diff of your "emacs with bug" and your "emacs without bug".

1. for emacs without bug

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x55627cc9d400>
x_make_frame_visible
set_window_configuration (4), MS=140x150 IH IV 

2. for patched emacs

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x5580c551de00>
set_window_configuration (4), MS=140x150 IH IV

RM>  And, if possible, run the version "without bug" under GDB and post a
RM>  backtrace from a position where it produces the "x_make_frame_visible"
RM>  line, somewhere around here in xterm.c:

RM>      if (!FRAME_VISIBLE_P (f))
RM>        {
RM>  	if (CONSP (frame_size_history))
RM>  	  frame_size_history_plain
RM>  	    (f, build_string ("x_make_frame_visible"));

RM>  	x_wait_for_event (f, MapNotify);
RM>        }

RM>  I cannot imagine how Emacs can get there without producing any recorded
RM>  events before or after it so it would be very interesting to find out
RM>  how it got there in the first place.

This one?

(gdb) bt
#0  builtin_lisp_symbol (index=0) at lisp.h:1008
#1  0x0000000000573854 in x_make_frame_visible (f=0x12815e8) at xterm.c:11686
#2  0x0000000000574044 in x_make_frame_visible_invisible
    (f=0x12815e8, visible=true) at xterm.c:11898
#3  0x000000000043bf11 in Fmake_frame_visible (frame=0x12815ed) at frame.c:2718
#4  0x000000000068f99d in funcall_subr
    (subr=0xe571c0 <Smake_frame_visible>, numargs=1, args=0x7fffffffa250)
    at eval.c:3126
#5  0x000000000068f47e in Ffuncall (nargs=2, args=0x7fffffffa248)
    at eval.c:3051
#6  0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda3a1a14, vector=0x7fffda3a0685, maxdepth=0x2e, args_template=0x402, nargs=1, args=0x7fffffffa7c0) at bytecode.c:632
#7  0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda3a0655, syms_left=0x402, nargs=1, args=0x7fffffffa7b8)
    at eval.c:3175
#8  0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda3a0655, nargs=1, arg_vector=0x7fffffffa7b8) at eval.c:3256
#9  0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffa7b0)
--Type <RET> for more, q to quit, c to continue without paging--
    at eval.c:3055
#10 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda3a1ad4, vector=0x7fffda3a0615, maxdepth=0xe, args_template=0x406, nargs=1, args=0x7fffffffae00) at bytecode.c:632
#11 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda3a05c5, syms_left=0x406, nargs=1, args=0x7fffffffadf8)
    at eval.c:3175
#12 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda3a05c5, nargs=1, arg_vector=0x7fffffffadf8) at eval.c:3256
#13 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffadf0)
    at eval.c:3055
#14 0x000000000068e1fb in Fapply (nargs=2, args=0x7fffffffadf0) at eval.c:2638
#15 0x000000000068f8a8 in funcall_subr
    (subr=0xe652c0 <Sapply>, numargs=2, args=0x7fffffffadf0) at eval.c:3106
#16 0x000000000068f47e in Ffuncall (nargs=3, args=0x7fffffffade8)
    at eval.c:3051
#17 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffd9ffb5c4, vector=0x7fffda06106d, maxdepth=0x3e, args_template=0x202, nargs=1, args=0x7fffffffb358) at bytecode.c:632
--Type <RET> for more, q to quit, c to continue without paging--
#18 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda06103d, syms_left=0x202, nargs=1, args=0x7fffffffb358)
    at eval.c:3175
#19 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda06103d, nargs=1, arg_vector=0x7fffffffb358) at eval.c:3256
#20 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffb350)
    at eval.c:3055
#21 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda38f9c4, vector=0x7fffda07505d, maxdepth=0x3a, args_template=0x402, nargs=1, args=0x7fffffffb948) at bytecode.c:632
#22 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda075025, syms_left=0x402, nargs=1, args=0x7fffffffb940)
    at eval.c:3175
#23 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda075025, nargs=1, arg_vector=0x7fffffffb940) at eval.c:3256
#24 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffb938)
    at eval.c:3055
#25 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda1842d4, vector=0x7fffda183fcd, maxdepth=0x1a, args_template--Type <RET> for more, q to quit, c to continue without paging--
=0x2, nargs=0, args=0x7fffffffbe60) at bytecode.c:632
#26 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda183f9d, syms_left=0x2, nargs=0, args=0x7fffffffbe60)
    at eval.c:3175
#27 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda183f9d, nargs=0, arg_vector=0x7fffffffbe60) at eval.c:3256
#28 0x000000000068f4d2 in Ffuncall (nargs=1, args=0x7fffffffbe58)
    at eval.c:3055
#29 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda188124, vector=0x7fffda174cb5, maxdepth=0x3a, args_template=0x2, nargs=0, args=0x7fffffffc918) at bytecode.c:632
#30 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda174c85, syms_left=0x2, nargs=0, args=0x7fffffffc918)
    at eval.c:3175
#31 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda174c85, nargs=0, arg_vector=0x7fffffffc918) at eval.c:3256
#32 0x000000000068f4d2 in Ffuncall (nargs=1, args=0x7fffffffc910)
    at eval.c:3055
#33 0x00000000006e73d5 in exec_byte_code
--Type <RET> for more, q to quit, c to continue without paging--
    (bytestr=0x7fffda18a49c, vector=0x7fffda17429d, maxdepth=0x26, args_template=0x2, nargs=0, args=0x7fffffffcfe0) at bytecode.c:632
#34 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda17426d, syms_left=0x2, nargs=0, args=0x7fffffffcfe0)
    at eval.c:3175
#35 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda17426d, nargs=0, arg_vector=0x7fffffffcfe0) at eval.c:3256
#36 0x000000000068fdfa in apply_lambda (fun=0x7fffda17426d, args=0x0, count=4)
    at eval.c:3200
#37 0x000000000068de35 in eval_sub (form=0x7fffda6afbeb) at eval.c:2573
#38 0x000000000068d1d3 in Feval (form=0x7fffda6afbeb, lexical=0x0)
    at eval.c:2355
#39 0x00000000005b4856 in top_level_2 () at keyboard.c:1126
#40 0x000000000068af6d in internal_condition_case
    (bfun=0x5b4833 <top_level_2>, handlers=0x90, hfun=0x5b4100 <cmd_error>)
    at eval.c:1478
#41 0x00000000005b489a in top_level_1 (ignore=0x0) at keyboard.c:1134
#42 0x000000000068a1c2 in internal_catch
    (tag=0xe730, func=0x5b4858 <top_level_1>, arg=0x0) at eval.c:1198
--Type <RET> for more, q to quit, c to continue without paging--
#43 0x00000000005b478b in command_loop () at keyboard.c:1094
#44 0x00000000005b3be1 in recursive_edit_1 () at keyboard.c:720
#45 0x00000000005b3deb in Frecursive_edit () at keyboard.c:792
#46 0x00000000005afea6 in main (argc=1, argv=0x7fffffffd568) at emacs.c:2310

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Bill! You married with Computer.
          Not with Me!"
         "No..., with money."





  reply	other threads:[~2021-08-29  2:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09  9:12 bug#49959: 28.0.50; Emacs got quasi freeze 野宮 賢 / NOMIYA Masaru
2021-08-18  8:03 ` martin rudalics
2021-08-21  5:09   ` Masaru Nomiya
     [not found]     ` <20210821072303.ead4637113305e2e518936b8@rasterman.com>
2021-08-21  6:54       ` Masaru Nomiya
2021-08-22  8:23         ` martin rudalics
2021-08-22  9:49           ` martin rudalics
2021-08-22 16:54             ` martin rudalics
2021-08-22 23:11               ` Masaru Nomiya
2021-08-23  8:35                 ` martin rudalics
2021-08-24  1:19                   ` Masaru Nomiya
2021-08-24  3:45                     ` Masaru Nomiya
2021-08-24  9:41                       ` martin rudalics
2021-08-24 12:35                         ` Masaru Nomiya
2021-08-24 14:14                           ` martin rudalics
2021-08-25 11:01                             ` Masaru Nomiya
2021-08-25 14:16                               ` martin rudalics
2021-08-26  0:24                                 ` Masaru Nomiya
2021-08-26  7:52                                   ` martin rudalics
2021-08-29  2:05                                     ` Masaru Nomiya [this message]
2021-08-29  7:21                                       ` martin rudalics
     [not found]                                         ` <875yvo8ywt.wl-nomiya@galaxy.dti.ne.jp>
     [not found]                                           ` <89382a57-874e-81ed-d71f-8301db63ba48@gmx.at>
     [not found]                                             ` <87h7f5oq0p.wl-m.nomiya@gmail.com>
2021-08-31 16:51                                               ` bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze) martin rudalics
2021-09-01  0:21                                                 ` Masaru Nomiya
2021-09-01  9:17                                                   ` martin rudalics
2021-09-01 10:05                                                     ` Masaru Nomiya
2022-08-22 11:59                                                       ` bug#49959: 28.0.50; Emacs got quasi freeze Lars Ingebrigtsen
2022-09-19 19:19                                                         ` Lars Ingebrigtsen
2022-09-19 21:45                                                           ` 野宮 賢 / NOMIYA Masaru

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

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

  git send-email \
    --in-reply-to=877dg580px.wl-nomiya@galaxy.dti.ne.jp \
    --to=nomiya@galaxy.dti.ne.jp \
    --cc=49959@debbugs.gnu.org \
    --cc=m.nomiya@gmail.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 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.