GNOME Bugzilla – Bug 758194
Memory corruption with g_strerror after a setlocale
Last modified: 2017-06-21 14:13:34 UTC
Created attachment 315707 [details] test program Compile the attached test program (according to the command in its first row) and run it. Expected output: The error message "Permission denied" printed 8 times, with various pointer values before them. Actual output: garbage: 0x7fff5d47e4f0 0x7fff5d47e4f0 � 0x0 (null) 0x7fff5d47e4f0 � 0x7fff5d47e4f0 0x7fff5d47e4f0 ����� 0x7fe10ac17dc0 0x7fff5d47e4f0 ����� The very first invocation of g_strerror() already returns an incorrect (empty) string. Next, a call to g_locale_from_utf8() which should not modify this string (it's a const gchar*) mangles it. According to g_strerror()'s doc, "the pointer is guaranteed to remain valid for the lifetime of the process". --- Works fine on Linux. Works fine without the setlocale() call. OS X Yosemite 10.10.5; Apple LLVM version 7.0.0 (clang-700.0.72) LANG=en_US.UTF-8; no LC_* variable set. glib-2.46.2 from mac ports. I just ran "port selfupdate; port upgrade outdated" today shortly before discovering this bug, so it might have sneaked in with this version. Originally discovered bug reported at http://www.midnight-commander.org/ticket/3558
Note: On Linux I tried with 2.46.1 (Wily), not with 2.46.2.
Can't reproduce on Linux with glib-2.46.2 either. So it has probably something to do with the different GNU vs. BSD strerror_r().
(In reply to Egmont Koblinger from comment #2) > Can't reproduce on Linux with glib-2.46.2 either. So it has probably > something to do with the different GNU vs. BSD strerror_r(). nope, has to do with a totally stupid bug in g_strerror() in the non-GNU strerror_r case :)
Created attachment 315709 [details] [review] Fix g_strerror() on non-glibc When using one of the codepaths that copies the error string into buf, make sure the string gets strdup() afterward. ====== Does this fix the problem?
Yes, it does fix the problem, thanks a lot!
2.44 had a different g_strerror() implementation and is not affected. The 2.46 series is buggy. I think this might have a negative effect on many other apps as well, not just Midnight Commander, and I'm not sure, but perhaps might lead to a crash as well. Could you please consider releasing a 2.46.3 tarball with this fix in the foreseeable future? Thanks again!
The patch was pushed as commit f87e002313d566dcce71a9aba040d22ddb5c1e80 and is present in all releases from 2.47.2 onwards (inclusive). (In reply to Egmont Koblinger from comment #6) > Could you please consider releasing a 2.46.3 tarball with this fix > in the foreseeable future? A 2.46.3 release is not going to happen at this point, since that release series is too old to care about. Looks like this is all resolved.