Bug 18207 - _initialize_python () may fail to restore initial locale in gdb configured with Python 3
Summary: _initialize_python () may fail to restore initial locale in gdb configured wi...
Status: RESOLVED DUPLICATE of bug 20037
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2015-04-07 11:03 UTC by Ilya Yu. Malakhov
Modified: 2016-05-06 20:51 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Ilya Yu. Malakhov 2015-04-07 11:03:12 UTC

 Currently there is a bug in _initialize_python () in recent gdb versions (including the one in master branch of binutils-gdb.git) configured with Python 3, which may show itself up when manipulating locales:

$ cat gdb/python/python.c
. . .
_initialize_python (void)
. . .
#ifdef IS_PY3K
  oldloc = setlocale (LC_ALL, NULL);
  setlocale (LC_ALL, "");
. . .
  setlocale (LC_ALL, oldloc);
. . .

 If the second setlocale () were to succeed, it might very well spoil the string OLDLOC pointed to after the first one, because of which the third setlocale () might fail. An obvious fix would be to strdup (OLDLOC) after the first call to setlocale and free () it in the end, of course.

 From a user's point of view this bug can make it impossible to enter floating-point numbers within gdb in a usual way, if his environment prevents '.' from being interpreted as a decimal point:

$ LC_ALL=ru_RU.KOI8-R gdb
. . .
(gdb) p 1.5
Invalid number "1.5".
. . .
Comment 1 Ilya Yu. Malakhov 2016-05-06 20:51:08 UTC
 Now that the problem described in Commit #0 has been fixed in Bug #20037 mark this bug as a duplicate of the latter.

*** This bug has been marked as a duplicate of bug 20037 ***