GNU bug report logs - #15863
Segmentation fault when traversing long lines

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15863 in the body.
You can then email your comments to 15863 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aaron France <aaron.l.france <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Segmentation fault when traversing long lines
Date: Mon, 11 Nov 2013 21:04:28 +0100

[Message part 1 (text/plain, inline)]

Hi,

M-x version

GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.2)\n of 
2013-11-11 on archbox.

I've compiled this myself in order to retrieve debug symbols. Hence the 
date.

I seem to consistently be able to make emacs segfault in both the slime 
repl and the rgrep results window. Whenever the line is unusually long 
(how long? About 2-300 chars long?) and then go to the end of the line, 
it segfaults.

I've got the gdb backtrace, which is in this link: 
https://gist.github.com/AeroNotix/368ada4c84e7a52f461d

I've tried to trace it through but I am not familiar with this source 
and it's quite a length and involved file.

Any help would be greatly appreciated.

Aaron

[Message part 2 (text/html, inline)]

Message #8 received at 15863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron France <aaron.l.france <at> gmail.com>
Cc: 15863 <at> debbugs.gnu.org
Subject: Re: bug#15863: Segmentation fault when traversing long lines
Date: Mon, 11 Nov 2013 22:33:17 +0200

> Date: Mon, 11 Nov 2013 21:04:28 +0100
> From: Aaron France <aaron.l.france <at> gmail.com>
> 
> I seem to consistently be able to make emacs segfault in both the slime 
> repl and the rgrep results window. Whenever the line is unusually long 
> (how long? About 2-300 chars long?) and then go to the end of the line, 
> it segfaults.

If this is consistent, can you provide a reproducible test case,
starting with "emacs -Q"?

> I've got the gdb backtrace, which is in this link: 
> https://gist.github.com/AeroNotix/368ada4c84e7a52f461d

Thanks, but it's hard to do anything with just this backtrace.  Can
you at least see what was the immediate reason for the crash?  E.g.,
is 'glyph' a NULL pointer?

Also, how come you get truncation glyphs on a GUI frame? did you
disable the fringes or something?

Thanks.

Message #11 received at 15863 <at> debbugs.gnu.org (full text, mbox):

From: Aaron France <aaron.l.france <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15863 <at> debbugs.gnu.org
Subject: Re: bug#15863: Segmentation fault when traversing long lines
Date: Mon, 11 Nov 2013 21:46:05 +0100

On 11/11/13 21:33, Eli Zaretskii wrote:
>> Date: Mon, 11 Nov 2013 21:04:28 +0100
>> From: Aaron France <aaron.l.france <at> gmail.com>
>>
>> I seem to consistently be able to make emacs segfault in both the slime
>> repl and the rgrep results window. Whenever the line is unusually long
>> (how long? About 2-300 chars long?) and then go to the end of the line,
>> it segfaults.
> If this is consistent, can you provide a reproducible test case,
> starting with "emacs -Q"?

"emacs" -Q does not reproduce the build.
>> I've got the gdb backtrace, which is in this link:
>> https://gist.github.com/AeroNotix/368ada4c84e7a52f461d
> Thanks, but it's hard to do anything with just this backtrace.  Can
> you at least see what was the immediate reason for the crash?  E.g.,
> is 'glyph' a NULL pointer?
>
> Also, how come you get truncation glyphs on a GUI frame? did you
> disable the fringes or something?
>
> Thanks.
I'll dig some more

Message #14 received at 15863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron France <aaron.l.france <at> gmail.com>
Cc: 15863 <at> debbugs.gnu.org
Subject: Re: bug#15863: Segmentation fault when traversing long lines
Date: Mon, 11 Nov 2013 23:09:18 +0200

> Date: Mon, 11 Nov 2013 21:46:05 +0100
> From: Aaron France <aaron.l.france <at> gmail.com>
> CC: 15863 <at> debbugs.gnu.org
> 
> On 11/11/13 21:33, Eli Zaretskii wrote:
> >> Date: Mon, 11 Nov 2013 21:04:28 +0100
> >> From: Aaron France <aaron.l.france <at> gmail.com>
> >>
> >> I seem to consistently be able to make emacs segfault in both the slime
> >> repl and the rgrep results window. Whenever the line is unusually long
> >> (how long? About 2-300 chars long?) and then go to the end of the line,
> >> it segfaults.
> > If this is consistent, can you provide a reproducible test case,
> > starting with "emacs -Q"?
> 
> "emacs" -Q does not reproduce the build.

Then perhaps you could add your customizations one by one until you
get to reproduce the problem, and then show the minimal set of
customizations that is enough to trigger it.

> I'll dig some more

Thank you.

Message #17 received at 15863 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Aaron France <aaron.l.france <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15863 <at> debbugs.gnu.org
Subject: Re: bug#15863: Segmentation fault when traversing long lines
Date: Mon, 29 Aug 2016 21:46:44 -0400

tags 15863 unreproducible
close 15863
quit

Aaron France <aaron.l.france <at> gmail.com> writes:

> On 11/11/13 21:33, Eli Zaretskii wrote:
>>> Date: Mon, 11 Nov 2013 21:04:28 +0100
>>> From: Aaron France <aaron.l.france <at> gmail.com>
>>>
>>> I seem to consistently be able to make emacs segfault in both the slime
>>> repl and the rgrep results window. Whenever the line is unusually long
>>> (how long? About 2-300 chars long?) and then go to the end of the line,
>>> it segfaults.
>> If this is consistent, can you provide a reproducible test case,
>> starting with "emacs -Q"?
>
> "emacs" -Q does not reproduce the build.
> I'll dig some more

Since there's been no update for a while, I'm closing as unreproducible.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.