GNU bug report logs - #9196
integer and memory overflow issues (e.g., cut-and-paste crashes Emacs)

Previous Next

Full log

Message #38 received at 9196 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9196 <at> debbugs.gnu.org
Subject: Re: bug#9196: integer and memory overflow issues (e.g., cut-and-paste
	crashes Emacs)
Date: Mon, 08 Aug 2011 20:01:48 +0200

Paul Eggert skrev 2011-08-06 03:24:
> On 08/05/2011 02:26 AM, Jan Djärv wrote:
>>> +      static char const xdefaults[] = ".Xdefaults-";
>>
>> I think there might be problems with dumping and static variables.
>> There is a reason for initializing static variables in init-functions
>> rather in an initializer.  I don't remember the details.
>
> In the old days, Emacs sometimes did '#define static /* empty */' as
> part of its undumping scheme, which meant that static variables inside
> functions didn't preserve their values from call to call.  Emacs no
> longer does that, so we're OK here.  (And even if Emacs still did
> that, this particular code would be safe, as this particular variable
> would be reinitialized to the correct value on every call.)

That is not what I meant.  Tale a look at xterm.c, syms_of_xterm.  Static 
variables are initialized there.  The manual says:

"   You must not use C initializers for static or global variables unless
the variables are never written once Emacs is dumped.  These variables
with initializers are allocated in an area of memory that becomes
read-only (on certain operating systems) as a result of dumping Emacs.
"

So I guess this usage is ok.

>
>>> +      char *home = gethomedir ();
>>> +      char const *host = get_system_name ();
>>> +      ptrdiff_t pathsize = strlen (home) + sizeof xdefaults + strlen (host);
>>> +      path = (char *) xrealloc (home, pathsize);
>>> +      strcat (strcat (path, xdefaults), host);
>>>          p = path;
>>>        }
>>>
>>>      db = XrmGetFileDatabase (p);
>>>
>>>      xfree (path);
>>> -  xfree (home);
>>
>> Since home isn't free:d, you have introduced a memory leak.
>
> No, we should be OK here -- the realloc frees 'home'.

Right, missed that.


	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.