Bug #1679: rb_w32_getenv() invalidates previous environment pointers

• Status: Closed
• Assignee: arton (Akio Tajima)
• Target version: 1.9.3
• ruby -v: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]

[jeremi_tu (Jarek Jurasz)]

=begin
On Windows turning on page heap (gflags -p /enable ruby.exe /full) revealed that environment pointers returned by rb_w32_getenv() get invalidated on the next call to this function due to the freeing of the environment buffer.
In particular getenv("RUBYLIB_PREFIX") in rubylib_mangle() frees getenv("RUBYLIB") fetched in ruby_init_loadpath(). This bug is also present in ruby 1.9.1-p129.

The workaround - the RTL version of getenv() - worked fine for me so far.
=end

[jeremi_tu (Jarek Jurasz)]

=begin
It does not know about SetEnvironmentVariable() in ruby_setenv() / hash.c.
GetEnvironmentVariable() needs some memory management.
The following leaky version passes the test.

char *
rb_w32_getenv(const char name)
{
char env[1024];
unsigned len = GetEnvironmentVariable(name, env, sizeof(env));
if (! len) {
map_errno(GetLastError());
return NULL;
}
/ Memory leak */
return strdup(env);
}
=end

[usa (Usaku NAKAMURA)]

• Category set to core

=begin
ISO C and POSIX say that the returned string may be overwritten by a subsequent call of getenv().
So, the behavior of rb_w32_getenv() is collect and the wrong point is rb_init_loadpath().
=end

[akr (Akira Tanaka)]

• Project changed from 8 to Ruby
• Category changed from core to core

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to arton (Akio Tajima)

[nahi (Hiroshi Nakamura)]

• Target version set to 1.9.3

[usa (Usaku NAKAMURA)]

In current trunk (at least), this problem is not occurred.
The return value of getenv("RUBY_LIB") is rb_str_new()'ed before another getenv() call.

[usa (Usaku NAKAMURA)]

• Status changed from Assigned to Closed