Re: editfns.c (Fformat): fix for segfault

[Kenichi Handa]

In article <address@hidden>, Jim Meyering <address@hidden> writes:

> I tried using a snapshot from today's CVS repository with Gnus.
> I got a segfault within a minute or two:

>   pi$ gdb --args  /p/bin/emacs -f gnus-no-server
>   (gdb) r
>   Starting program: /u/p/bin/emacs -f gnus-no-server

>   Program received signal SIGSEGV, Segmentation fault.
>   0x081718e2 in Fformat (nargs=4, args=0xbfffe194)
>       at /mirror/d/emacs/src/editfns.c:3486
>   3486              discarded[format - format_start] = 1;
>   (gdb) p format
>   $1 = (unsigned char *) 0x91788b4 "%S %d %d y\n"
>   (gdb) p format_start
>   $2 = (unsigned char *) 0x90cff34 "%s %d %d y\n"

Thank you for the report.  I found a problem in the code of
Fformat.

> This patch seems to have fixed it, at least to the extent
> that with it, I can no longer reproduce the problem.
[...]
>    /* Scan the format and store result in BUF.  */
>    format = SDATA (args[0]);
> +  format_start = format;
> +  end = format + SBYTES (args[0]);
>    maybe_combine_byte = 0;
>    while (format != end)
>      {

I think it's not enough.

This is my analysis.  In the first scan, Fchar_to_string or
Fprint1_to_string are called, and they will relocate a data
of a Lisp string (in the current case, args[0]).  When that
happens, the area pointed to by `format' becomes invalid.
So, after each call of them, we must update format,
format_start, and end.  Another way is to copy the byte
sequence of args[0] into some safe area alloced or malloced.

Could some Emacs developper confirm my analysis and, if it
is correct, fix the code along this line.  Currently, I
don't have a time to do that by myself.

---
Ken'ichi HANDA
address@hidden