| Summary: | _initialize_python () may fail to restore initial locale in gdb configured with Python 3 | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Ilya Yu. Malakhov <malakhov> |
| Component: | python | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | pedro |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
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 *** |
Hi. 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 . . . void _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". . . .