Re: emacs-24.3: test request

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sun, Sep 08, 2013 at 13:25:52 +0400, Valery Ushakov wrote:

> On Sun, Sep 08, 2013 at 10:13:13 +0100, Robert Swindells wrote:
> 
> > Thomas Klausner wrote:
> > >On Sun, Sep 08, 2013 at 11:59:51AM +0400, Valeriy E. Ushakov wrote:
> > >> Haven't you or someone else complained about problems with emacs24
> > >> vs. environ a few months ago?
> > 
> > >This is still the same issue I've been seeing and reporting for
> > >months. There is a random element in the backtrace (sometimes it even
> > >works! perhaps my stack limit test was a random success), but it
> > >usually ends in getenv and below, trying some to find some language
> > >environment stuff.
> > 
> > If you run:
> > 
> > % nm emacs | sort > lst
> > 
> > What variables are just below environ in memory ?
> 
> emacs plays games with environ itself, saving and restoring it.  A
> problem in that code is more likely than random buffer overflow that
> clobbers environ.


With the following breakpoints on assignemnts to/from environ:

break callproc.c:496
break callproc.c:643
break callproc.c:1314
break editfns.c:1912
break editfns.c:1940
break editfns.c:1941
break editfns.c:2119
break editfns.c:2177
break process.c:1734
break process.c:1879



Starting program: /usr/pkgsrc/editors/emacs24/work/emacs-24.3/src/emacs-24.3.1 
/usr/pkgsrc/doc/guide/files/options.xml
Gtk-Message: Failed to load module "canberra-gtk-module"
[Switching to LWP 1]

Breakpoint 4, Fencode_time (nargs=9, args=0x7f7fffff74e8) at editfns.c:1912
1912          char **oldenv = environ, **newenv;
(gdb) p environ
$1 = (char **) 0x11f3400
(gdb) watch *(char **)0x11f3400 
Watchpoint 11: *(char **)0x11f3400
(gdb) n

Breakpoint 8, set_time_zone_rule (tzstring=0x7f7fffff7330 "XXX-0:00:00")
    at editfns.c:2177
2177      environ = newenv;
(gdb) 
2220    }
(gdb) p environ
$3 = (char **) 0x15c9800
(gdb) n
Fencode_time (nargs=9, args=0x7f7fffff74e8) at editfns.c:1937
1937          value = mktime (&tm);
(gdb) 
Watchpoint 11: *(char **)0x11f3400

Old value = 0x7f7ffffffd2d "PILOTRATE=115200"
New value = 0x1476400 ""
_free_internal_nolock (ptr=0x11f3400) at gmalloc.c:1224
1224              prev->prev = &_fraghead[type];
(gdb) p environ
$4 = (char **) 0x15c9800
(gdb) bt
#0  _free_internal_nolock (ptr=0x11f3400) at gmalloc.c:1224
#1  0x0000000000664ecf in _free_internal (ptr=0x11f3400) at gmalloc.c:1241
#2  0x0000000000664f1e in free (ptr=0x11f3400) at gmalloc.c:1255
#3  0x00007f7fec4b2beb in ?? () from /usr/lib/libc.so.12
#4  0x00007f7fec4b2dc7 in __getenvslot () from /usr/lib/libc.so.12
#5  0x00007f7fec4b2f42 in __findenvvar () from /usr/lib/libc.so.12
#6  0x00007f7fec4b29e0 in getenv () from /usr/lib/libc.so.12
#7  0x00007f7fec4ab594 in ?? () from /usr/lib/libc.so.12
#8  0x00007f7fec4ab85f in __localtime_r50 () from /usr/lib/libc.so.12
#9  0x0000000000679a16 in ranged_convert (
    convert=0x4114a0 <__localtime_r50@plt>, t=0x7f7fffff7240, 
    tp=0x7f7fffff7200) at mktime.c:310
#10 0x0000000000679e2f in mktime_internal (tp=0x7f7fffff73a0, 
    convert=0x4114a0 <__localtime_r50@plt>, offset=0xc06250) at mktime.c:478
#11 0x000000000067a15b in rpl_mktime (tp=0x7f7fffff73a0) at mktime.c:591
#12 0x00000000005b89c7 in Fencode_time (nargs=9, args=0x7f7fffff74e8)
    at editfns.c:1937
[...]


So it looks like libc is confused by changed environ (see
stdlib/_env.c in libc).

Unfortunately, I have to run now and can only look further into it
late tonight at the earliest.  If someone feels like picking this up
from here, feel free to.  TIA.

-uwe