Re: [Nano-devel] Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64

[David Lawrence Ramsey]

Simon Strandman wrote:
> Hi!
>
> Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64 when I search in a
> document. Version 1.2.5 however is stable.
>
> This is the backtrace:

<snip>

> I believe this is because suse patches their glibc with a patch that
> adds amd64 optimized strings. Adding the same patch to gentoo's glibc
> makes nano crash the same way there too.
>
> More info about the amd64 patch and the problem:
> http://bugs.gentoo.org/show_bug.cgi?id=100289

Actually, there is a case in 1.3.8-cvs where the parameter passed to
that particular renumber() could be NULL (if s is equal to "", and the
match for it is the blank line at the bottom of the history list), so
I've added a NULL guard to it.  Thanks for indirectly catching it, by
the way.

However, I don't believe that that parameter should be NULL in the case
your backtrace is showing.  If "fsd" exists in the history when
update_history() is called, the entry after it, which is passed to
renumber(), should either be another string or the blank line at the
bottom of the history list.  In short, the entry after "fsd" should
never be NULL if "fsd" exists in the history.  And if "fsd" doesn't
exist in the history, find_history() should return NULL, and that
renumber() should never be reached at all.

Thanks for the report and the link, in any case.  How does current CVS
behave?  I imagine that renumbering won't be done properly in all cases
due to the above problem, but at least it shouldn't segfault.