pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: emacs-24.3: test request



On Sun, Sep 08, 2013 at 14:23:47 +0400, Valery Ushakov wrote:

> 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).

Ah, it's __scrubenv() that clobbers it:

ssize_t
__getenvslot(const char *name, size_t l_name, bool allocate)
{
        size_t new_size, num_entries, required_size;
        char **new_environ;

        /* Does the environ need scrubbing? */
        if (environ != allocated_environ && allocated_environ != NULL)
           __scrubenv();


> 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


Home | Main Index | Thread Index | Old Index