Bug 639089

Summary: gdb-heap installation breaks gdb.base/charset.exp: print the null character in ASCII
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: dmalcolm, jan.kratochvil, pmuldoon, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: gdb-7.2-23.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-28 06:07:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backtrace of where the exception occurs (autoloading the gdb-heap code)
none
GDB fix. none

Description Jan Kratochvil 2010-09-30 19:25:45 UTC
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?

Comment 1 Dave Malcolm 2010-09-30 19:56:16 UTC
FWIW, I think that the:
  LookupError: unknown encoding: IBM1047
message is coming from Python/codecs.c:_PyCodec_Lookup

Comment 2 Dave Malcolm 2010-09-30 20:31:23 UTC
Created attachment 450881 [details]
Backtrace of where the exception occurs (autoloading the gdb-heap code)

Comment 3 Dave Malcolm 2010-09-30 20:35:23 UTC
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)

Comment 4 Dave Malcolm 2010-09-30 20:40:05 UTC
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.

Comment 5 Tom Tromey 2010-09-30 20:55:39 UTC
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.

Comment 6 Tom Tromey 2010-09-30 21:09:01 UTC
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.

Comment 7 Jan Kratochvil 2010-10-06 23:27:40 UTC
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.

Comment 8 Tom Tromey 2010-10-07 19:25:19 UTC
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 9 Jan Kratochvil 2010-10-08 19:12:43 UTC
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

Comment 10 Fedora Update System 2010-10-13 02:55:26 UTC
gdb-7.2-22.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gdb-7.2-22.fc14

Comment 11 Fedora Update System 2010-10-13 06:10:34 UTC
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

Comment 12 Fedora Update System 2010-10-14 15:42:46 UTC
gdb-7.2-23.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gdb-7.2-23.fc14

Comment 13 Fedora Update System 2010-10-28 06:07:06 UTC
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.