Re: [bug #48463] segmentation fault

[Gavin Smith]

On 14 July 2016 at 16:58, mtsio <address@hidden> wrote:
> I think I discovered what causes the crash. In apropos_in_all_indices
> (indices.c) at line 605 we are freeing up some memory (free
> (this_fb->contents;). If I delete these lines it works correctly but
> what is the root cause of that I'm not sure. The closer I got is that
> when the address of win->node->contents is 'close' to this_fb->contents
> and we free the second one we also messing up with win->node->contents.
> If the info file we search for is big these two could overlap.
>
> Is something like that possible?

Yes, I believe you are right. It's possible for win->node->contents to
point into the middle of the block pointed to by this_fb->contents. It
doesn't always happen (for example, if the character encoding has been
converted), so that could be why I didn't reproduce the crash.

The code that frees this_fb->contents is wrong. I'm fairly sure that I
put that code there in the first place: my best guess is that I wasn't
thinking about the interactive command "M-x index-apropos" and only
thinking of the "--apropos" command-line option.

I think that it is worth trying to conserve memory for an index
apropos search, because there can potentially be many manuals
installed on a system and loading them all into memory could be too
wasteful.

Measured with the "top" command (followed by "On" to sort by memory usage):

Running ginfo, followed by "M-x index-apropos RET gettext RET": the
memory in the VIRT column (virtual memory in kilobytes) is 20736.

If I comment out the lines to free the memory, recompile, and do the
same test, I get the usage up to 57952.

I've attached my work so far on a fix, which frees the file only when
the file had to be loaded. Because I haven't been able to replicate
the crash you got, I'm not sure for certain if it solves the problem.

info-fix-crash.patch
Description: Text Data