Re: emacs-24.3: test request

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

On Sun, Sep 08, 2013 at 14:36:41 +0400, Valery Ushakov wrote:

> Date: Sun, 8 Sep 2013 14:36:41 +0400
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> To: Robert Swindells <rjs%fdy2.co.uk@localhost>, wiz%NetBSD.org@localhost,
>       pkgsrc-users%NetBSD.org@localhost, current-users%NetBSD.org@localhost
> Subject: Re: emacs-24.3: test request
> Mail-Followup-To: Robert Swindells <rjs%fdy2.co.uk@localhost>, 
> wiz%NetBSD.org@localhost,
>       pkgsrc-users%NetBSD.org@localhost, current-users%NetBSD.org@localhost
> 
> On Sun, Sep 08, 2013 at 14:23:47 +0400, Valery Ushakov wrote:
> 
> > 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();

This is from

----------------------------
revision 1.4
date: 2010-11-16 20:23:10 +0300;  author: tron;  state: Exp;  lines: +60 -13;
Implement mark & sweep garbage collection as suggested by Enami Tsugutomo
on "current-users" mailing list. Garbage collection is performed if:
1.) We previously allocated memory for the environment array which
    is no longer used because the application overwrote "environ".
2.) We find a non-NULL pointer in the allocated environment array after
    the end of the environment. This happens if the applications attempts
    to clear the environment with something like "environ[0] = NULL;".

and I think it has to be reverted, since you can't do g/c if you don't
know all roots.

-uwe