Re: Segfaults in libc-2.19 w/ 2.9.2

Hi Benno,

On Wed, 17 Jan 2018, at 20:06, Benno Schulenberg wrote:

> In your markdown.nanorc I cannot find anything suspicious.
> There seem to be some superfluous backslashes in there, but
> they shouldn't cause any problem.  Although... who knows?
> For example, in this line: color green "\*[^\* ]\*"

Thanks for checking and your feedback. Apparently, I never had a 
closer look at this markdown.nanorc. The `[^\* ]` is not the only 
nonsense in there :| Shouldn't cause a problem but it is simply wrong 
in the sense that it does not highlight text as intended.

>>>> What can I do to track this down?
>
> How do you compile your nano?  With what configure options?
> Please show the output of 'nano --version'.

$ "nano" --version
  GNU nano, version 2.9.2
  (C) 1999-2011, 2013-2017 Free Software Foundation, Inc.
  (C) 2014-2017 the contributors to nano
  Email: [email protected]	Web: https://nano-editor.org/
  Compiled options: --disable-libmagic --enable-utf8

To compile I ran

   configure --prefix=/usr/local/testing --enable-utf8 && make

I understand that `--enable-utf8` is not needed. It's a historic 
switch I used on systems that were not yet set to UTF-8 only.

> And what CFLAGS do you use?  'echo $CFLAGS'

CFLAGS = -g -O2 -Wall

> Even better, Brand Huntsman has posted a patch that should
> produce a backtrace automatically whenever nano would crash:
>
>  http://lists.gnu.org/archive/html/nano-devel/2018-01/msg00064.html
>
> However, after applying the patch, nano fails to compiler for me.
> But... maybe in a few days Brand will post a version that does work.

Thanks a lot for this and for the cross references on both lists. I 
see Brand Huntsman already posted an updated patch in
http://lists.gnu.org/archive/html/nano-devel/2018-01/msg00097.html

For now I wait until the crash occurs again.

As I am not subscribed to nano-devel I'd like to highlight here what 
you wrote in
http://lists.gnu.org/archive/html/nano-devel/2018-01/msg00068.html

>>> But this also does an endwin(), which means that it wipes all of 
>>> nano and its content from the screen and restores the terminal to 
>>> what it looked like before nano started.  I don't think I would 
>>> like that.  I want to see the content of the screen at the point 
>>> that nano crashed.

Both times when nano crashed I was able to copy-paste and preserve 
most of the text I had just written. That would have been a pity if 
nano had cleared the screen in the course of the crash.

-- 
-- Andreas

     :-)