[Bug 55835] New: putenv clobbers previous getenv
https://bugs.winehq.org/show_bug.cgi?id=55835 Bug ID: 55835 Summary: putenv clobbers previous getenv Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: blitzkriegoutlaw(a)hotmail.com Distribution: --- Created attachment 75335 --> https://bugs.winehq.org/attachment.cgi?id=75335 Sample code performing a putenv/_putenv_s to an empty string will clobber a previous getenv. There may be other cases, but this is the one I ran into. I've attached sample code. On Windows it returns: AMD64 Family 23 Model 1 Stepping 2, AuthenticAMD AMD64 Family 23 Model 1 Stepping 2, AuthenticAMD On Wine it returns: x86 Family 6 Model 79 Stepping 1, GenuineIntel Family 6 Model 79 Stepping 1, GenuineIntel The string is globbered by the _setenv_s due to the shift in memory by removing another environment variable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Bartosz <gang65(a)poczta.onet.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gang65(a)poczta.onet.pl -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #1 from Eric Pouech <eric.pouech(a)gmail.com> --- took a quick glance at it: tested on Win10. 32bit version looks it behaves as Wine (_environ[] points to a global chunk of memory containing all pointers) while 64bit has a different allocation for each string in _environ[]). do you have an application that depends on this behavior? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #2 from blitzkriegoutlaw(a)hotmail.com --- I worked around it by copying the value to a local variable. It took me a while to track it down as what was happening didn't make sense immediately. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #3 from Eric Pouech <eric.pouech(a)gmail.com> --- can you share which application it is (if possible) Side note: comment in #2 about difference between 32 & 64 bit is inacurate. Further testings show that they both behave the same way and msvcrt provides a distinct allocation bucket for each entry in the _environ[] array (native seems to do this separate allocation __after__ an entry is added/removed/updated, so order of operation matters) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #4 from blitzkriegoutlaw(a)hotmail.com --- It is internal software so not publicly available. I can't state what it is. The unix man page for getenv states: The implementation of getenv() is not required to be reentrant. The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3). The Microsoft help page has no such note. However, that part of the code compiles and runs on Windows and Linux and I don't have this problem. That unix note probably doesn't apply to Linux as haven't seen the problem there. It wasn't until I tried to run our legacy HMI in Wine that I ran into this problem. Since I have the source code, it wasn't hard to work around the issue by copying the result of getenv into an character array. I believe it is a bug since Windows getenv is reentrant. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to blitzkriegoutlaw from comment #4)
It is internal software so not publicly available. I can't state what it is. Nevermind. It's always interesting to log in bug entry if app is public, so that it can be retested afterwards. When possible.
The unix man page for getenv states: The implementation of getenv() is not required to be reentrant. The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3).
The Microsoft help page has no such note. However, that part of the code compiles and runs on Windows and Linux and I don't have this problem. That unix note probably doesn't apply to Linux as haven't seen the problem there. It wasn't until I tried to run our legacy HMI in Wine that I ran into this problem. Since I have the source code, it wasn't hard to work around the issue by copying the result of getenv into an character array. I believe it is a bug since Windows getenv is reentrant. yes, msvcrt puts in place a per-entry allocation in _environ (and _wenviron) (so that _environ[i] isn't changed after a putenv if variable isn't stored at location [i])
so, it looks like for native: - (w)getenv("foo") is unchanged (pointer value and pointed string) after (w)putenv calls, iff "foo" variable isn't modified - I would be less confident in the stability of the index inside _(w)environ[]. I haven't tested what happens if one removes a variable at index before i. I fear it could well be that the _(w)environ array is compacted, moving the entry at _(w)environ[i-1]. Anyway, I posted https://gitlab.winehq.org/wine/wine/-/merge_requests/4313 that should solve your issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #6 from Bartosz <gang65(a)poczta.onet.pl> --- The issue was already resolved and it should be closed as fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #7 from Eric Pouech <eric.pouech(a)gmail.com> --- actually it's not fixed (yet) MR 4313 has been reduced in scope and only contains mainly tests (and a fix for something not related to this bug) fix for this bug has been moved into MR 4377 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 --- Comment #8 from Eric Pouech <eric.pouech(a)gmail.com> --- this should be fixed by commit bdb624fffb1c1acc1feb2baec396d9b805cb0ce9 can you retest from git tree or when wine 8-21 is released? TIA -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #9 from Piotr Caban <piotr.caban(a)gmail.com> --- The attached example works as expected now. Marking as fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55835 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla