Bug #1679
closedrb_w32_getenv() invalidates previous environment pointers
Description
=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
Updated by jeremi_tu (Jarek Jurasz) about 15 years ago
=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
Updated by usa (Usaku NAKAMURA) about 15 years ago
- 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
Updated by akr (Akira Tanaka) over 13 years ago
- Project changed from Ruby to Ruby master
- Category changed from core to core
Updated by naruse (Yui NARUSE) over 13 years ago
- Status changed from Open to Assigned
- Assignee set to arton (Akio Tajima)
Updated by nahi (Hiroshi Nakamura) over 13 years ago
- Target version set to 1.9.3
Updated by usa (Usaku NAKAMURA) over 13 years ago
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.
Updated by usa (Usaku NAKAMURA) over 13 years ago
- Status changed from Assigned to Closed