Bug 10908 - error reading variable for char variable
Summary: error reading variable for char variable
Alias: None
Product: gdb
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.0
: P2 normal
Target Milestone: 7.3
Assignee: Not yet assigned to anyone
: 11519 (view as bug list)
Depends on:
Reported: 2009-11-05 14:55 UTC by Egor
Modified: 2010-12-21 15:26 UTC (History)
4 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Egor 2009-11-05 14:55:17 UTC
#include <stdio.h>

main() {
char cc = 'z';
printf("cc=%c", cc); // STOP HERE
return 0;

Stop in the provided sample:
(gdb) print cc
$1 = 122 '<error reading variable>

Reproduced on Solaris 10 and OpenSolaris
Comment 1 Paul Pluzhnikov 2009-11-07 01:57:35 UTC
This has to do with Tom's charset changes. The error comes from:

#0  error (string=0x834d468 "%s.") at ../../src/gdb/utils.c:814
#1  0x080d5c33 in perror_with_name (
    string=0x8373763 "Converting character sets") at ../../src/gdb/utils.c:1147
#2  0x0815aa33 in make_wchar_iterator (input=0x80470c0 "z9W\b\001", bytes=1, 
    charset=0xfe65b0d0 "UTF-8", width=1) at ../../src/gdb/charset.c:542
#3  0x0821370a in c_emit_char (c=122, type=0x8573988, stream=0x852e388, 
    quoter=39) at ../../src/gdb/c-lang.c:272
#4  0x08213a1d in c_printchar (c=122, type=0x8573988, stream=0x852e388)
    at ../../src/gdb/c-lang.c:360
#5  0x08235ea8 in c_val_print (type=0x8573988, valaddr=0x85a8918 "z�U\b", 
    embedded_offset=0, address=134511147, stream=0x852e388, recurse=0, 
    options=0x8047370) at ../../src/gdb/c-valprint.c:497
#6  0x081739c7 in val_print (type=0x8573988, valaddr=0x85a8918 "z�U\b", 
    embedded_offset=0, address=134511147, stream=0x852e388, recurse=0, 
    options=0x8047430, language=0x83a7dc0) at ../../src/gdb/valprint.c:309
#7  0x082365e9 in c_value_print (val=0x85f3558, stream=0x852e388, 
    options=0x8047510) at ../../src/gdb/c-valprint.c:711
#8  0x08173bf1 in value_print (val=0x85f3558, stream=0x852e388, 
    options=0x8047510) at ../../src/gdb/valprint.c:393
#9  0x08175ef3 in print_formatted (val=0x85f3558, size=0, options=0x8047510, 
    stream=0x852e388) at ../../src/gdb/printcmd.c:319
#10 0x08177156 in print_command_1 (exp=0x8449dea "cc", inspect=0, voidprint=1)
    at ../../src/gdb/printcmd.c:958

Possible workaround: install GNU libiconv into the build tree.
Comment 2 Paul Pluzhnikov 2009-11-07 19:21:45 UTC
The first problem appears to be that iconv_open("wchar_t", "UTF-8") fails.

Here are the relevant ICONV settings from config.h:

$ egrep 'ICONV|WCHAR|BTOWC' config.h 
#define HAVE_BTOWC 1
#define HAVE_ICONV 1
/* #undef HAVE_ICONVLIST */
#define HAVE_WCHAR_H 1
#define ICONV_CONST const
#define WCHAR_T_SUFFIX l

The second problem is that 'iconv -l' outputs this:

$ iconv -l
The following are all supported code set names.  All combinations
of those names are not necessarily available for the pair of the
fromcode-tocode.  Some of those code set names have aliases, which
are case-insensitive and described in parentheses following the
canonical name:
    646 (ASCII, US-ASCII, US_ASCII, USASCII), 646da, 646de,
    646en, 646es, 646fr, 646it, 646sv, 8859,
    8859-1 (ISO8859-1, ISO-8859-1, ISO8859_1, ISO_8859_1),

This results in bizarre tab completion for 'set charset ...':
(gdb) set charset <TAB>
All               combinations      not
Some              described         of
The               following         pair
aliases,          for               parentheses
all               fromcode-tocode.  set
and               have              supported
are               in                the
available         name:             those
canonical         names             which
case-insensitive  names.            
code              necessarily       

and inability to set charset to anything reasonable:

(gdb) set charset UTF-8
Undefined item: "UTF-8".

Comment 3 Tom Tromey 2009-11-07 22:29:28 UTC
> The first problem appears to be that iconv_open("wchar_t", "UTF-8") fails.

This was discussed on the list, though it never resulted in a working

I think we should completely disable the iconv stuff for solaris.
It might work with libiconv, I am not sure, but even if so, if
there is no libiconv we must fall back on nothing -- the solaris iconv
is unusable by gdb.
Comment 4 Tom Tromey 2010-04-19 22:49:15 UTC
*** Bug 11519 has been marked as a duplicate of this bug. ***
Comment 5 Rainer Orth 2010-04-22 18:49:34 UTC
Subject: Re:  error reading variable for char variable

I've just asked the OpenSolaris i18n mailing list for advise:


While there's a project to fix this issue, the current recommendation
was to disable iconv support.  I've tried your patch on
i386-pc-solaris2.11 and it works just fine, so I'd really like to get
this in until Solaris can properly handle iconv.

Comment 6 Ilya Basin 2010-12-10 13:05:52 UTC
I couldn't find an option to disable iconv, but this worked for me:
am_cv_func_iconv=no ./configure

Note that it isn't "./configure am_cv_func_iconv=no", because the configure script in root dir doesn't pass am_cv_func_iconv to the configure script in gdb dir.
Comment 7 Tom Tromey 2010-12-21 15:26:00 UTC
I put in a fix a while back that disables the use of 
iconv on many systems, including Solaris.
The change will appear in gdb 7.3.

One thing that would be useful in the future is to know how to
write a test to see whether a newer Solaris has a working iconv.
Ideally, this test would not require running a test program.
For glibc this is easy because it defines __STDC_ISO_10646__,
but from the referenced thread I gather that this will never
be the case on Solaris.