Several problems

Several problems

[David Kastrup]

Current master (as of

    commit c7dc7052d94a19476bd8037d680162fd7f51c361
    Merge: 399fe8b aab3459
    Author: Glenn Morris <rgm@gnu.org>
    Date:   Mon Jul 28 05:39:09 2014 -0400

        Merge from emacs-24; up to r117412

in the Git mirror) has several problems for me.  Gnus startup fails to
connect to my POP server (via TLS/SSL) as well as the NNTP server at
news.gmane.org.  I can go through with C-g, go from *Group* into
*Server* with ^, then open the NNTP server from *there*.

Reverting

    commit 4c19675328d0de84cc3181cfc118973f591e8243
    Author: Dmitry Antipov <dmantipov@yandex.ru>
    Date:   Mon Jul 28 10:28:15 2014 +0400

        On GNU/Linux, use timerfd for asynchronous timers.
        * configure.ac (toplevel): Check whether GNU/Linux-specific
        timerfd functions and macros are available.
        * m4/clock_time.m4 (gl_CLOCK_TIME): Check for clock_getres as well.
        * src/atimer.c (toplevel) [HAVE_TIMERFD]: Include sys/timerfd.h.
        (toplevel): Rename alarm_timer_ok to special_timer_available.
        [HAVE_TIMERFD]: Declare timerfd.
        [HAVE_CLOCK_GETRES]: Declare resolution.
        (start_atimer) [HAVE_CLOCK_GETRES]: Round up timestamp to
        system timer resolution.
        (set_alarm) [HAVE_TIMERFD]: Use timerfd_settime.
        (timerfd_callback) [HAVE_TIMERFD]: New function.
        (atimer_result, debug_timer_callback, Fdebug_timer_check)
        [ENABLE_CHECKING]: New function for the sake of automated tests.
        (init_atimer) [HAVE_TIMERFD]: Setup timerfd.
        [HAVE_CLOCK_GETRES]: Likewise for system timer resolution.
        [ENABLE_CHECKING]: Defsubr test function.
        * src/atimer.h (timerfd_callback) [HAVE_TIMERFD]: Add prototype.
        * src/lisp.h (add_timer_wait_descriptor) [HAVE_TIMERFD]: Likewise.
        * src/process.c (add_timer_wait_descriptor) [HAVE_TIMERFD]: New function.
        * test/automated/timer-tests.el (timer-tests-debug-timer-check): New test.

might have done the trick here, but I only was able to do very few
experiments because of the horizontal scroll bar code crashing on me
whenever I restore the desktop (which involves restoring the window
configuration).

_That_ crash would have been

(gdb) bt
#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb69460c6 in raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0x08124299 in terminate_due_to_signal (sig=sig@entry=6, 
    backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:387
#3  0x0813cef7 in emacs_abort () at ../../emacs/src/sysdep.c:2198
#4  0x080f3e38 in XTredeem_scroll_bar (w=0x8752f30)
    at ../../emacs/src/xterm.c:5948
#5  0x0809dd4a in redisplay_window (window=window@entry=141897525, 
    just_this_one_p=just_this_one_p@entry=false)
    at ../../emacs/src/xdisp.c:16839
#6  0x080a16be in redisplay_window_0 (window=141897525)
    at ../../emacs/src/xdisp.c:14250
#7  0x0819280a in internal_condition_case_1 (
    bfun=0x80a1690 <redisplay_window_0>, arg=141897525, handlers=139030854, 
    hfun=0x806cd10 <redisplay_window_error>) at ../../emacs/src/eval.c:1371
#8  0x0807133d in redisplay_windows (window=6) at ../../emacs/src/xdisp.c:14230
#9  0x080901ac in redisplay_internal () at ../../emacs/src/xdisp.c:13829
#10 0x08091d45 in redisplay () at ../../emacs/src/xdisp.c:13115
#11 0x0812e40d in read_char (commandflag=1, map=map@entry=156740206, 
    prev_event=139049922, used_mouse_menu=used_mouse_menu@entry=0xbfffee6b, 
    end_time=end_time@entry=0x0) at ../../emacs/src/keyboard.c:2560
#12 0x0812fd80 in read_key_sequence (keybuf=keybuf@entry=0xbfffef08, 
    prompt=139049922, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at ../../emacs/src/keyboard.c:9120
#13 0x08131796 in command_loop_1 () at ../../emacs/src/keyboard.c:1438
#14 0x08192713 in internal_condition_case (
    bfun=bfun@entry=0x81315e0 <command_loop_1>, handlers=139083250, 
    hfun=hfun@entry=0x8128c50 <cmd_error>) at ../../emacs/src/eval.c:1347
#15 0x081246b5 in command_loop_2 (ignore=139049922)
    at ../../emacs/src/keyboard.c:1169
#16 0x08192643 in internal_catch (tag=139077146, 
    func=func@entry=0x8124690 <command_loop_2>, arg=139049922)
    at ../../emacs/src/eval.c:1111
#17 0x081288b2 in command_loop () at ../../emacs/src/keyboard.c:1148
#18 recursive_edit_1 () at ../../emacs/src/keyboard.c:769
#19 0x08128b99 in Frecursive_edit () at ../../emacs/src/keyboard.c:840
#20 0x08059768 in main (argc=<optimized out>, argv=0xbffff154)
    at ../../emacs/src/emacs.c:1650

My Emacs is configured to use GTK but --without-toolkit-scroll-bars.
For now I've rewound my Emacs version to before the horizontal
scroll-bar commit since I would not be able to get any work done
otherwise.

I fully realize that both of these error reports, particularly the
timer-related one, are flimsy on facts, and I would not bet my life
savings on the first one being reliably dependent on the timer code commit.

They probably will be worth acting upon mostly when other reports
solidify their findings.  Since the state of Emacs current master gives
me is too fragile for working because of _several_ problems, I'm not
likely going to be able to contribute much more useful info.

Sorry.

-- 
David Kastrup

Re: Several problems

[Dmitry Antipov]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On 07/28/2014 03:24 PM, David Kastrup wrote:

> in the Git mirror) has several problems for me.  Gnus startup fails to
> connect to my POP server (via TLS/SSL) as well as the NNTP server at
> news.gmane.org.  I can go through with C-g, go from *Group* into
> *Server* with ^, then open the NNTP server from *there*.

Argh, sorry for that, and please try this patch.

I do not use Gnus on a regular basics, but I definitely should
run it just to test important changes in core subsystems... :-(

Dmitry


[-- Attachment #2: timerfd.patch --]
[-- Type: text/x-patch, Size: 822 bytes --]

=== modified file 'src/atimer.c'
--- src/atimer.c	2014-07-28 06:28:15 +0000
+++ src/atimer.c	2014-07-28 12:00:35 +0000
@@ -413,6 +413,10 @@
 void
 timerfd_callback (int fd, void *arg)
 {
+  char buf[8];
+  ptrdiff_t nbytes = emacs_read (fd, buf, sizeof (buf));
+  /* Just discard an expiration count for now.  */
+  eassert (nbytes == sizeof (buf));
   do_pending_atimers ();
 }
 

=== modified file 'src/process.c'
--- src/process.c	2014-07-28 06:28:15 +0000
+++ src/process.c	2014-07-28 11:48:51 +0000
@@ -6835,7 +6835,9 @@
 void
 add_timer_wait_descriptor (int fd)
 {
+  FD_SET (fd, &input_wait_mask);
   FD_SET (fd, &non_keyboard_wait_mask);
+  FD_SET (fd, &non_process_wait_mask);  
   fd_callback_info[fd].func = timerfd_callback;
   fd_callback_info[fd].data = NULL;
   fd_callback_info[fd].condition |= FOR_READ;

Re: Several problems

[martin rudalics]

 > the horizontal scroll bar code crashing on me
 > whenever I restore the desktop (which involves restoring the window
 > configuration).
 >
 > _That_ crash would have been
 >
 > (gdb) bt
 > #0  0xb7fdd424 in __kernel_vsyscall ()
 > #1  0xb69460c6 in raise (sig=sig@entry=6)
 >      at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
 > #2  0x08124299 in terminate_due_to_signal (sig=sig@entry=6,
 >      backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:387
 > #3  0x0813cef7 in emacs_abort () at ../../emacs/src/sysdep.c:2198
 > #4  0x080f3e38 in XTredeem_scroll_bar (w=0x8752f30)
 >      at ../../emacs/src/xterm.c:5948
 > #5  0x0809dd4a in redisplay_window (window=window@entry=141897525,
 >      just_this_one_p=just_this_one_p@entry=false)
 >      at ../../emacs/src/xdisp.c:16839
 > #6  0x080a16be in redisplay_window_0 (window=141897525)
 >      at ../../emacs/src/xdisp.c:14250
[...]
 >
 > My Emacs is configured to use GTK but --without-toolkit-scroll-bars.
 > For now I've rewound my Emacs version to before the horizontal
 > scroll-bar commit since I would not be able to get any work done
 > otherwise.

As a first attempt could you please try the patch below?


=== modified file 'src/window.h'
--- src/window.h	2014-07-27 13:21:30 +0000
+++ src/window.h	2014-07-28 12:19:52 +0000
@@ -787,7 +787,7 @@

  /* Say whether horizontal scroll bars are currently enabled for window
     W.  Horizontal scrollbars exist for toolkit versions only.  */
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (HAVE_NTGUI)
+#if defined (USE_X_TOOLKIT) || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS)) || defined (HAVE_NTGUI)
  #define WINDOW_HAS_HORIZONTAL_SCROLL_BAR(W)			\
    ((WINDOW_PSEUDO_P (W) || MINI_NON_ONLY_WINDOW_P (W))		\
     ? false							\


I'm afraid that desktop still won't work satisfactorily due to other
issues but maybe the crash gets fixed this way.

Thanks, martin

Re: Several problems

[Ted Zlatanov]

Hello David and Dmitry,

I see the following situation (using the Git mirror):

* Dmitry's commit 4c19675328d0de84cc3181cfc118973f591e8243 broke GnuTLS
  connections and possibly more. I couldn't even do the initial
  connection.

* the followup fix was good for the initial connection, but larger
  amounts of data fail:

commit 85113e79cb92f1d2798db5754a9edd54567d2b0e
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Jul 28 18:50:55 2014 +0400

    Fix Gnus-related issues reported by David Kastrup <dak@gnu.org> in
    <http://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00370.html>.
    * atimer.c (timerfd_callback): Always read expiration data.
    Add comment.
    (turn_on_atimers) [HAVE_TIMERFD]: Disarm timerfd timer.
    * process.c (add_timer_wait_descriptor): Add timer descriptor
    to input_wait_mask and non_process_wait_mask as well.

I've only tested with GnuTLS connections.

The symptom seems to be that GnuTLS will read data, then gets a retry,
and finally hangs forever. I can duplicate it by trying to read the last
200 messages in emacs-devel and I believe even as little as 16K will
trigger the behavior. But if I read the last 1 message only (`C-u 1
RET') then things work.  If this is indeed a timer problem, it will be
hard to replicate but I hope this is enough data.

It would be nice if we could automate the testing of this behavior.  It
can probably be done with a TLS server (`gnutls-serv' for instance) but
in my experience that's a very tricky type of test that tends to throw
spurious errors.  So it may just be something we live with.

I have probably missed the discussion about this timerfd feature (having
just come back from vacation), so please forgive my ignorance, but is
this something that should always be enabled, or can it be configurable?
If it interferes with GnuTLS connections, maybe it should be disabled
for them?

I am following up to emacs-devel instead of opening a bug report because
that's where David Kastrup posted initially.  If you prefer a bug
report, let me know.

Thanks!
Ted

Re: Several problems

[Ted Zlatanov]

I can confirm after testing that reverting Dmitry's timerfd commits in a
local Git repo brings GnuTLS back to usable:

commit 58d06704bf38581a7fc4e7e44702176bd9d65c76
Author: Ted Zlatanov <tzz@lifelogs.com>
Date:   Wed Jul 30 16:04:08 2014 -0400

    Revert "On GNU/Linux, use timerfd for asynchronous timers."
    
    This reverts commit 4c19675328d0de84cc3181cfc118973f591e8243.
    
    Conflicts:
        src/ChangeLog
        test/ChangeLog

commit fbee9036f9d2d786948b7be9447e8d1a6b24030b
Author: Ted Zlatanov <tzz@lifelogs.com>
Date:   Wed Jul 30 16:02:53 2014 -0400

    Revert "Fix Gnus-related issues reported by David Kastrup <dak@gnu.org> in"
    
    This reverts commit 85113e79cb92f1d2798db5754a9edd54567d2b0e.

I hope that's helpful :)  The only conflicts are in the ChangeLog files
as usual, so this is a simple workaround until we figure the problem out.

Thanks
Ted

Re: Several problems

[Dmitry Antipov]

On 07/31/2014 12:02 AM, Ted Zlatanov wrote:

> The symptom seems to be that GnuTLS will read data, then gets a retry,
> and finally hangs forever. I can duplicate it by trying to read the last
> 200 messages in emacs-devel and I believe even as little as 16K will
> trigger the behavior. But if I read the last 1 message only (`C-u 1
> RET') then things work.  If this is indeed a timer problem, it will be
> hard to replicate but I hope this is enough data.

Is it possible to create a simple recipe?  I'm not familiar enough with Gnus, and
would like to see something like in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16603#5.

> If you prefer a bug report, let me know.

Yes, please.

Dmitry

Re: Several problems

[Nicolas Avrutin]

I'm also experiencing this issue and would be happy to help you with
testing. I'm also using gtk3 and --without-toolkit-scroll-bars. I can
trigger the crash by running (sauron-start)[1] or
(jabber-connect-all)[2], in xmonad sending any emacs frame to a
different workspace, and then going to the workspace to which I sent the
frame.

I have applied your patch and the crash still occurs. Here is my
backtrace after running it through addr2line[3]:

emacs_backtrace at emacs-git/src/sysdep.c:2182
terminate_due_to_signal at emacs-git/src/emacs.c:381
emacs_open at emacs-git/src/sysdep.c:2211
XTredeem_scroll_bar at emacs-git/src/xterm.c:5971
redisplay_window at emacs-git/src/xdisp.c:16845
redisplay_window_0 at emacs-git/src/xdisp.c:14251
internal_condition_case_1 at emacs-git/src/eval.c:1371
redisplay_windows at emacs-git/src/xdisp.c:14235
redisplay_internal at emacs-git/src/xdisp.c:13829
redisplay at emacs-git/src/xdisp.c:13116
read_char at emacs-git/src/keyboard.c:2562
read_key_sequence at emacs-git/src/keyboard.c:9120 (discriminator 4)
command_loop_1 at emacs-git/src/keyboard.c:1438
internal_condition_case at emacs-git/src/eval.c:1347
command_loop_2 at emacs-git/src/keyboard.c:1169 (discriminator 1)
internal_catch at emacs-git/src/eval.c:1111
command_loop at emacs-git/src/keyboard.c:1149
recursive_edit_1 at emacs-git/src/keyboard.c:769
Frecursive_edit at emacs-git/src/keyboard.c:841
main at emacs-git/src/emacs.c:1652


Let me know if you'd prefer that I file a bug about this.
Thanks


Footnotes: 
[1]  https://github.com/djcb/sauron
[2]  http://emacs-jabber.sourceforge.net/
[3]  sed -n 's/.*\[\(.*\)]$/\1/p' backtrace | addr2line -p -C -f -i -e
`which emacs`

-- 
Nicolas Avrutin

Re: Several problems

[martin rudalics]

 > I'm also experiencing this issue and would be happy to help you with
 > testing.

Thank you.

 > I'm also using gtk3 and --without-toolkit-scroll-bars. I can
 > trigger the crash by running (sauron-start)[1] or
 > (jabber-connect-all)[2], in xmonad sending any emacs frame to a
 > different workspace, and then going to the workspace to which I sent the
 > frame.
 >
 > I have applied your patch and the crash still occurs. Here is my
 > backtrace after running it through addr2line[3]:
 >
 > emacs_backtrace at emacs-git/src/sysdep.c:2182
 > terminate_due_to_signal at emacs-git/src/emacs.c:381
 > emacs_open at emacs-git/src/sysdep.c:2211
 > XTredeem_scroll_bar at emacs-git/src/xterm.c:5971
 > redisplay_window at emacs-git/src/xdisp.c:16845

It's the same problem David encountered.  Apparently, when setting up
horizontal scrool bars I somewhere blindly use USE_GTK without checking
whether it also uses toolkit scroll bars.  So I have to go through the
code and find the culprit.  As soon as I've found it I'll tell you.

martin

Re: Several problems

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]

David Kastrup wrote:

 > the horizontal scroll bar code crashing on me
 > whenever I restore the desktop (which involves restoring the window
 > configuration).
 >
 > _That_ crash would have been
 >
 > (gdb) bt
 > #0  0xb7fdd424 in __kernel_vsyscall ()
 > #1  0xb69460c6 in raise (sig=sig@entry=6)
 >     at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
 > #2  0x08124299 in terminate_due_to_signal (sig=sig@entry=6,
 >     backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:387
 > #3  0x0813cef7 in emacs_abort () at ../../emacs/src/sysdep.c:2198
 > #4  0x080f3e38 in XTredeem_scroll_bar (w=0x8752f30)
 >     at ../../emacs/src/xterm.c:5948

Nicolas Avrutin wrote:

 > I'm also experiencing this issue and would be happy to help you with
 > testing. I'm also using gtk3 and --without-toolkit-scroll-bars. I can
 > trigger the crash by running (sauron-start)[1] or
 > (jabber-connect-all)[2], in xmonad sending any emacs frame to a
 > different workspace, and then going to the workspace to which I sent the
 > frame.
 >
 > I have applied your patch and the crash still occurs. Here is my
 > backtrace after running it through addr2line[3]:
 >
 > emacs_backtrace at emacs-git/src/sysdep.c:2182
 > terminate_due_to_signal at emacs-git/src/emacs.c:381
 > emacs_open at emacs-git/src/sysdep.c:2211
 > XTredeem_scroll_bar at emacs-git/src/xterm.c:5971

Faried Nawaz wrote:

 > I'm not on the mailing list, and I'm not sure where to report bugs, but I
 > ran into the same crash as David Kastrup today, after I pulled and built
 > from trunk.  Your patch in
 > http://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00373.html doesn't
 > fix the problem for me.
 >
 > I'm not sure how to reliably trigger the problem, but this usually works
 > for me.  I start Emacs under gdb, with -Q, and then evaluate these lines:
 >
 > (require 'package)
 > (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
 >                           ("marmalade" . "http://marmalade-repo.org/packages/
 > ")
 >                           ("melpa" . "http://melpa.milkbox.net/packages/")))
 > (package-initialize)
 >
 > I run M-x list-packages RET and switch away to another virtual desktop.
 > Some combination of switching away/switching back, or partially covering
 > the frame with an xterm before switching causes the crash for me.  It might
 > be timer related, too -- it doesn't happen immediately, but after a while.
 > It takes a while to fetch the packages list.
 >
 > The backtrace is at https://gist.github.com/faried/f1a01fac78a790f32ebe
 >
 > I use Ubuntu 12.04 (fully updated, 32-bit) and I compile Emacs with
 >
 > ./configure --without-pop --with-x-toolkit=lucid \
 >      --prefix=/usr/local/src --without-toolkit-scroll-bars \
 >      --enable-link-time-optimization --without-compress-install \
 >      --with-file-notification=yes
 >
 > I hope this helps locate the cause of the problem.

Please try the attached patch and tell me whether the problem persists.

Thank you, martin

[-- Attachment #2: gtk-non-toolkit-scroll-bars.diff --]
[-- Type: text/plain, Size: 2575 bytes --]

=== modified file 'src/frame.c'
--- src/frame.c	2014-08-01 00:04:52 +0000
+++ src/frame.c	2014-08-01 12:25:36 +0000
@@ -3793,7 +3793,9 @@
 void
 x_set_horizontal_scroll_bars (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 {
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (HAVE_NTGUI)
+#if defined (USE_X_TOOLKIT)						\
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))		\
+  || defined (HAVE_NTGUI)
   if ((NILP (arg) && FRAME_HAS_HORIZONTAL_SCROLL_BARS (f))
       || (!NILP (arg) && !FRAME_HAS_HORIZONTAL_SCROLL_BARS (f)))
     {
@@ -3844,7 +3846,9 @@
 void
 x_set_scroll_bar_height (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 {
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (HAVE_NTGUI)
+#if defined (USE_X_TOOLKIT)						\
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))		\
+  || defined (HAVE_NTGUI)
   int unit = FRAME_LINE_HEIGHT (f);

   if (NILP (arg))

=== modified file 'src/frame.h'
--- src/frame.h	2014-07-28 08:07:55 +0000
+++ src/frame.h	2014-08-01 12:56:37 +0000
@@ -852,11 +852,17 @@
 #define FRAME_VERTICAL_SCROLL_BAR_TYPE(f) ((f)->vertical_scroll_bar_type)
 #define FRAME_HAS_VERTICAL_SCROLL_BARS(f) \
   ((f)->vertical_scroll_bar_type != vertical_scroll_bar_none)
-#define FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) \
+#if defined (USE_X_TOOLKIT)						\
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))		\
+  || defined (HAVE_NTGUI)
+#define FRAME_HAS_HORIZONTAL_SCROLL_BARS(f)	\
   ((f)->horizontal_scroll_bars)
-#define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_LEFT(f) \
+#else
+#define FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) false
+#endif
+#define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_LEFT(f)		\
   ((f)->vertical_scroll_bar_type == vertical_scroll_bar_left)
-#define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_RIGHT(f) \
+#define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_RIGHT(f)		\
   ((f)->vertical_scroll_bar_type == vertical_scroll_bar_right)

 #else /* not HAVE_WINDOW_SYSTEM */

=== modified file 'src/window.h'
--- src/window.h	2014-07-27 13:21:30 +0000
+++ src/window.h	2014-08-01 12:26:58 +0000
@@ -787,7 +787,9 @@

 /* Say whether horizontal scroll bars are currently enabled for window
    W.  Horizontal scrollbars exist for toolkit versions only.  */
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (HAVE_NTGUI)
+#if defined (USE_X_TOOLKIT)						\
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))		\
+  || defined (HAVE_NTGUI)
 #define WINDOW_HAS_HORIZONTAL_SCROLL_BAR(W)			\
   ((WINDOW_PSEUDO_P (W) || MINI_NON_ONLY_WINDOW_P (W))		\
    ? false							\

Re: Several problems

[Nicolas Avrutin]

Your patch fails to compile for me:
frame.c: In function ‘make_initial_frame’:
frame.c:863:40: error: lvalue required as left operand of assignment
   FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
                                        ^
frame.c: In function ‘make_terminal_frame’:
frame.c:916:40: error: lvalue required as left operand of assignment
   FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
                                        ^


With your patch, FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) is defined to be
false (the else branch, frame.h:858), resulting in the lines in frame.c
macro expanding to false = false;. As a workaround, I attempted the
following:
diff --git a/src/frame.c b/src/frame.c
index 457024f..ea96fce 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -860,7 +860,11 @@ make_initial_frame (void)
 
 #ifdef HAVE_WINDOW_SYSTEM
   f->vertical_scroll_bar_type = vertical_scroll_bar_none;
+  #if defined (USE_X_TOOLKIT)                                          \
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))          \
+  || defined (HAVE_NTGUI)
   FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
+  #endif
 #endif
 
   /* The default value of menu-bar-mode is t.  */
@@ -913,7 +917,11 @@ make_terminal_frame (struct terminal *terminal)
 
 #ifdef HAVE_WINDOW_SYSTEM
   f->vertical_scroll_bar_type = vertical_scroll_bar_none;
+  #if defined (USE_X_TOOLKIT)                                          \
+  || (defined (USE_GTK) && defined (USE_TOOLKIT_SCROLL_BARS))          \
+  || defined (HAVE_NTGUI)
   FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
+  #endif
 #endif


This allows it to successfully compile, but the crash still occurs.

Thanks
-- 
Nicolas Avrutin

Re: Several problems

[Eli Zaretskii]

> From: Nicolas Avrutin <nicolasavru@gmail.com>
> Date: Sat, 02 Aug 2014 00:10:08 -0400
> Cc: David Kastrup <dak@gnu.org>, Faried Nawaz <faried@gmail.com>,
> 	emacs-devel@gnu.org
> 
> Your patch fails to compile for me:
> frame.c: In function ‘make_initial_frame’:
> frame.c:863:40: error: lvalue required as left operand of assignment
>    FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
>                                         ^
> frame.c: In function ‘make_terminal_frame’:
> frame.c:916:40: error: lvalue required as left operand of assignment
>    FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
>                                         ^
> 
> 
> With your patch, FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) is defined to be
> false (the else branch, frame.h:858), resulting in the lines in frame.c
> macro expanding to false = false;

How can this happen?  The definition of
FRAME_HAS_HORIZONTAL_SCROLL_BARS on frame.h is this:

  #ifdef HAVE_WINDOW_SYSTEM

  /* This frame slot says whether scroll bars are currently enabled for frame F,
     and which side they are on.  */
  #define FRAME_VERTICAL_SCROLL_BAR_TYPE(f) ((f)->vertical_scroll_bar_type)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS(f) \
    ((f)->vertical_scroll_bar_type != vertical_scroll_bar_none)
  #define FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) \
    ((f)->horizontal_scroll_bars)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_LEFT(f) \
    ((f)->vertical_scroll_bar_type == vertical_scroll_bar_left)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_RIGHT(f) \
    ((f)->vertical_scroll_bar_type == vertical_scroll_bar_right)

  #else /* not HAVE_WINDOW_SYSTEM */

  /* If there is no window system, there are no scroll bars.  */
  #define FRAME_VERTICAL_SCROLL_BAR_TYPE(f) ((void) f, vertical_scroll_bar_none)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS(f) ((void) f, 0)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_LEFT(f) ((void) f, 0)
  #define FRAME_HAS_VERTICAL_SCROLL_BARS_ON_RIGHT(f) ((void) f, 0)
  #define FRAME_HAS_HORIZONTAL_SCROLL_BARS(f) ((void) f, 0)

  #endif /* HAVE_WINDOW_SYSTEM */

IOW, it is only defined as a constant zero when HAVE_WINDOW_SYSTEM is
_not_ defined.  Whereas line 863 of frame.c is this:

  #ifdef HAVE_WINDOW_SYSTEM
    f->vertical_scroll_bar_type = vertical_scroll_bar_none;
    FRAME_HAS_HORIZONTAL_SCROLL_BARS (f) = false;
  #endif

IOW, it only treats FRAME_HAS_HORIZONTAL_SCROLL_BARS as an lvalue when
HAVE_WINDOW_SYSTEM _is_ defined.  And in that case, the definition of
FRAME_HAS_HORIZONTAL_SCROLL_BARS is not a constant.

So please look closer at your sources and try to figure out what
caused this strange problem.

Re: Several problems

[Nicolas Avrutin]

On Sat, Aug 02 2014, Eli Zaretskii <eliz@gnu.org> wrote:

> So please look closer at your sources and try to figure out what
> caused this strange problem.

This was a test of the patch that Martin Rudalics sent yesterday[1], not
the trunk code. His patch changes the definition of
FRAME_HAS_HORIZONTAL_SCROLL_BARS. Apologies if the header in my diff
caused any confusion.

Footnotes: 
[1]  http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00010.html

-- 
Nicolas Avrutin

Re: Several problems

[Eli Zaretskii]

> From: Nicolas Avrutin <nicolasavru@gmail.com>
> Cc: rudalics@gmx.at, dak@gnu.org, faried@gmail.com, emacs-devel@gnu.org
> Date: Sat, 02 Aug 2014 03:28:37 -0400
> 
> On Sat, Aug 02 2014, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > So please look closer at your sources and try to figure out what
> > caused this strange problem.
> 
> This was a test of the patch that Martin Rudalics sent yesterday[1], not
> the trunk code.

In that case, you know now how to fix the compilation problem
properly.

Re: Several problems

[martin rudalics]

 > So please look closer at your sources and try to figure out what
 > caused this strange problem.

Nicloas is currently heroically trying to help me fix a crash on
--without-toolkit-scroll-bars builds and I sent him a wrong (because
untested on such systems) patch.  I'm now doing a GTK3 build for the
first time --without-toolkit-scroll-bars here and hopefully will come up
with a better patch soon.  So long bear with me.

Thanks, martin

Re: Several problems

[martin rudalics]

 >  > #0  0xb7fdd424 in __kernel_vsyscall ()
 >  > #1  0xb69460c6 in raise (sig=sig@entry=6)
 >  >     at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
 >  > #2  0x08124299 in terminate_due_to_signal (sig=sig@entry=6,
 >  >     backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:387
 >  > #3  0x0813cef7 in emacs_abort () at ../../emacs/src/sysdep.c:2198
 >  > #4  0x080f3e38 in XTredeem_scroll_bar (w=0x8752f30)
 >  >     at ../../emacs/src/xterm.c:5948

[...]

 >  > emacs_backtrace at emacs-git/src/sysdep.c:2182
 >  > terminate_due_to_signal at emacs-git/src/emacs.c:381
 >  > emacs_open at emacs-git/src/sysdep.c:2211
 >  > XTredeem_scroll_bar at emacs-git/src/xterm.c:5971

[...]

 > > #0 0x00132416 in __kernel_vsyscall ()
 > > #1 0x00c79dde in raise () from /lib/i386-linux-gnu/libpthread.so.0
 > > #2 0x081fc07e in terminate_due_to_signal (sig=6, backtrace_limit=<optimized out>)
 > > at emacs.c:387
 > > #3 0x081fc0b2 in emacs_abort () at sysdep.c:2198
 > > #4 0x081ff6e8 in XTredeem_scroll_bar.51380 (w=0x8730508) at xterm.c:6003

I checked in a fix.  Please try again.

Thanks, martin

Re: Several problems

[Nicolas Avrutin]

On Mon, Aug 04 2014, martin rudalics <rudalics@gmx.at> wrote:
> I checked in a fix.  Please try again.

Looks good so far; I haven't been able to reproduce the crash. If it
crashes again, I'll send an email.

-- 
Nicolas Avrutin

Re: Several problems

[martin rudalics]

> Looks good so far; I haven't been able to reproduce the crash. If it
> crashes again, I'll send an email.

Faried, how does it behave for you now?

martin

Re: Several problems

[Faried Nawaz]

On Tue, Aug 5, 2014 at 1:36 PM, martin rudalics <rudalics@gmx.at> wrote:

> Faried, how does it behave for you now?

I haven't seen any crashes for about 30 minutes.  I've updated some
packages, edited local files, etc.  So far so good.

I built against

revno: 117648
branch nick: trunk
timestamp: Tue 2014-08-05 10:25:28 +0200


Thanks,

Faried.

Re: Several problems

[martin rudalics]

> I haven't seen any crashes for about 30 minutes.  I've updated some
> packages, edited local files, etc.  So far so good.

Fine.  If you see anything anormal, please report it ASAP.

martin