Description of problem: There is a testcase regression by installing gdb-heap. (that is by its auto-load) Version-Release number of selected component (if applicable): gdb-heap-0.5-2.fc14.x86_64 gdb-7.2-16.fc14.x86_64 python-2.7-8.fc14.1.x86_64 glibc-2.12.90-14.x86_64 How reproducible: Always. Steps to Reproduce: yum install gdb gdb-heap cat >cmd <<EOH shell echo 'main(){}'|gcc -o 1 -x c - file ./1 set host-charset IBM1047 set target-charset ASCII start print '\0' EOH ../gdb -nx <cmd Actual results: $1 = LookupError: unknown encoding: IBM1047 0 '<?><?><?><?>' Expected results: $1 = 0 '\000' Additional info: Does anyone have a clue before digging more?
FWIW, I think that the: LookupError: unknown encoding: IBM1047 message is coming from Python/codecs.c:_PyCodec_Lookup
Created attachment 450881 [details] Backtrace of where the exception occurs (autoloading the gdb-heap code)
Looks like it happens during the gdb.Command registration: frame 4 has: #4 0x0000003b51ebb496 in PyUnicodeUCS4_FromEncodedObject (obj='Print a report on memory usage, by category', encoding=0xd6b7b0 "IBM1047", errors=0x0) at /usr/src/debug/Python-2.7/Objects/unicodeobject.c:1172 which is the help text for the "heap" command. Should the help texts be "unicode", rather than "str"? (They are docstrings though)
Changing them to unicode leads to a similar failure, except that it's calling: PyUnicodeUCS4_AsEncodedString instead. Looks like Python doesn't know about IBM1047 (neither do I, for that matter), and that anything that leads to an encode from/decode to unicode will lead to a failure.
Does gdb actually work with this host charset? I would be mildly surprised; according to IANA it is an EBCDIC variant: http://www.iana.org/assignments/charset-reg/IBM1047 I suspect that gdb has various ASCII assumptions in it (though offhand I do not know where). Also, do we ship an IBM1047-based locale? It is only really valid to set host-charset to match the locale's charset. On the Python side... it seems to me that Python should use the system iconv. At least, it should on glibc systems, where iconv is good; on other systems I can't really recommend it.
Also -- if this is a gdb test case, then it is a little funny, but maybe ok if IBM1047 isn't supposed to "really" work. In this case maybe we should make -nx also disable python auto-loading.
Created attachment 452012 [details] GDB fix. I will check it more on Friday but GDB seems to violate: http://docs.python.org/c-api/exceptions.html # If the error is not handled or carefully propagated, additional calls into the # Python/C API may not behave as intended and may fail in mysterious ways.
I don't think this patch is ideal. It would be better to find the correct place to put an error check and a call to gdbpy_print_stack.
Comment on attachment 452012 [details] GDB fix. [patch] python(+solib error): save/restore error state http://sourceware.org/ml/gdb-patches/2010-10/msg00153.html
gdb-7.2-22.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gdb-7.2-22.fc14
gdb-7.2-22.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gdb'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gdb-7.2-22.fc14
gdb-7.2-23.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gdb-7.2-23.fc14
gdb-7.2-23.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.