bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 09:25:23 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 17281@debbugs.gnu.org
> 
> Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 10:13:02 +0300:
> > > Date: Thu, 17 Apr 2014 08:10:37 +0200
> > > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > > 
> > > In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
> > >  of 2014-03-31 on pille
> > > 
> > > commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
> > 
> > Thanks for the report, but please don't cite git sha1 values alone to
> > specify a commit; please show the full commit log message instead.  As
> > long as we use bzr as the primary VCS, git sha values don't bring
> > enough information to identify a commit, not without some extra work.
> 
> Sorry,
> 
> commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
> Author: Dmitry Antipov <dmantipov@yandex.ru>
> Date:   Mon Mar 31 11:13:58 2014 +0400
> 
>     * search.c (Freplace_match): Use make_specified_string.
>     * xterm.c, w32term.c (x_set_glyph_string_gc): Use emacs_abort
>     to catch bogus override face of glyph strings.

Thanks.

> > > Stripping this down it seems, that (next-line) is the problem.
> > 
> > Sounds like another duplicate of 17269.  Does setting cache-long-scans
> > to nil solve the problem?
> 
> No it does not solve it.

Then it's a different bug.  Are you sure it didn't happen before the
above commit?  I seem to be able to reproduce it as far back as Mar 15
(I have no easy way of trying older versions, due to changes in Lisp
files involved in this recipe).