Re: Segmentation fault while searching backward

[Peter Stephenson <pws@xxxxxxx>]

=?UTF-8?Q?J=C3=B6rg?= Sommer wrote:
> (gdb) print ollen
> $3 = 6
> 
> (gdb) x/16cb ol
> 0x101c31a0:     0 '\0'  0 '\0'  0 '\0'  0 '\0'  0 '\0'  0 '\0'  0 '\0'  108 '
> l'
> 0x101c31a8:     0 '\0'  0 '\0'  0 '\0'  101 'e' 0 '\0'  0 '\0'  0 '\0'  110 '
> n'

Thanks for the extra info... I think there is an extra line here (to
make six characters of four bytes each) but I'm already a bit worried
because the first character appears to be a NULL which should make the
length zero.

> > and what it's trying to put on screen (the contents of the array nl and
> > its length nllen).
> 
> (gdb) print nl
> $6 = (REFRESH_STRING) 0x101c2784
> (gdb) print *nl
> $7 = 62
> (gdb) print nllen
> $8 = 16
> 
> (gdb) x/24cb nl
> 0x101c2784:     0 '\0'  0 '\0'  0 '\0'  62 '>'  0 '\0'  0 '\0'  0 '\0'  46 '.
> '
> 0x101c278c:     0 '\0'  0 '\0'  0 '\0'  46 '.'  0 '\0'  0 '\0'  0 '\0'  46 '.
> '
> 0x101c2794:     0 '\0'  0 '\0'  0 '\0'  46 '.'  0 '\0'  0 '\0'  0 '\0'  32 ' 
> '

... and also an extra five lines here (making 64 bytes)

> > Note the arrays will be wide character strings.  If it's reproducible
> > with these two lines we have a chance of fixing it.
> 
> I can send you the core file (the executables and debugging symbols are
> from Debian) and the broken history file. It's reproducible.

With a bit of luck the history file will tell me enough: it will needed
to be synced with the internal history; if you use incappendhistory or
sharehistory it automatically will be.  If it's OK it would good to get
that (you can send it to me directly).  What are you typing after ^R to
get this to happen?

It would be preferable to sort this out before making a release, if
possible, and I'm on holiday for two weeks from tomorrow, so it might be
best if I make another dev release (incorporating the Solaris fixes)
today.

pws