Problem with unsigned char* data

Problem with unsigned char* data

[Emilio Ugo GIUFFRIDA]

Gentlemens,

I have a problem with gdb/Insight :-(

On a board, when a "unsigned char *" pointer is badly initialized to 
0xffffffff( that for us is outside the memory ), trying to print the pointer's value in the local variable window or in the watchpoint window makes the GUI crash.

Using the gdb console, the answer is quite verbose, but correct:
(gdb) print pt1
$6 = 
Error: Error in st200emu :  Cannot read buffer at memory adress 0xffffffff Adaptor error on: read memory access at address  (Exception 5 while executing ROM command)

It seems that gdb tries to read at 0xffffffff and, for pointers to unsigned char, displays by default the string pointed. 

Do you know if there is a gdb option disabling this behaviour?

The files of the gui involved in the variables display are variables.tcl, local.tcl and watch.tcl .

Where is the point, in the code, where the gui tells the gdb to read the local variables?

Inside variables.tcl there is a procedure, getLocals, that calls gdb_get_locals command ( located in gdbtk-stack.c ), but it isn't called from noone.

Can you help me?

Best regards,

Emilio

--------------------------------------------------------------------------

  			     Emilio Ugo Giuffrida

ST200 Tools Team                        Phone   : +39 0957404514
CMG/MCDT Software Design Center         Fax     : +39 0957404013
ST Microelectronics                     TINA    : 052 4514
Stradale Primosole, 50 			    e-mail  : emilio.giuffrida@st.com
95121 Catania ITALY     

--------------------------------------------------------------------------

Re: Problem with unsigned char* data

[Keith Seitz]

On Fri, 2004-05-21 at 03:30, Emilio Ugo GIUFFRIDA wrote:
> It seems that gdb tries to read at 0xffffffff and, for pointers to unsigned char, displays by default the string pointed. 
> 
> Do you know if there is a gdb option disabling this behaviour?

I'm sure there is a way, but for the life of me, I cannot recall/find
what it is. Hopefully another reader out there remembers.

> Where is the point, in the code, where the gui tells the gdb to read the local variables?

The variable stuff is all called from a gdb module called "varobj"
(short for variable objects). The actual updating of the variables
happens in VarTree::update_var:

    if {[catch {$var value} value]} {
      set color $colors(error)
    }

The first line asks the variable object to update itself. Eventually,
this will call varobj_update in src/gdb/varobj.c. You could set a break
on this function in gdb and step through it.

Hint: It sounds like you have a reproducible test case. Here's what I
would do. Get to the place in your program where you are ready to print
"pt1". Enter this variable into the watch window. This way, when
varobj_update is called, you don't have to filter through the twenty
calls from the update of all the local variables in the locals window.

That aside, two questions:
Do you have a stack backtrace for the crash?
What version of insight are you using? variables.tcl has been gone for
quite some time...

Keith

PS. Stupid thing to try: grab a newer version of varobj.c and drop it on
top of your older insight/gdb sources.

RE: Problem with unsigned char* data

[Emilio Ugo GIUFFRIDA]

I've resolved the problem! 

I found the a way to disabling the string pointed by an address   :-))

In the file c-valprint.c, in the function c_val_print  , there is this
function call :

				i = val_print_string (addr, -1, TYPE_LENGTH
(elttype), stream);

that if returns 0 everything has gone well.

The piece of code is:
if (TYPE_LENGTH (elttype) == 1
	      && TYPE_CODE (elttype) == TYPE_CODE_INT
	      && (format == 0 || format == 's')
	      && addr != 0)

	i = val_print_string (addr, -1, TYPE_LENGTH (elttype), stream);
else ....


To disable the behaviour simply replace the function call with :
							i = 0 ;

Of course it is a workaround, but I think it could be useful if you want to
be able to ON/OFF the printing of the string pointed by an address by
inserting a radio button in the GUI.

Bye,

Emilio

-----Original Message-----
From: Keith Seitz [mailto:keiths@redhat.com] 
Sent: Friday, May 21, 2004 4:50 PM
To: Emilio Ugo GIUFFRIDA
Cc: insight@sources.redhat.com
Subject: Re: Problem with unsigned char* data


On Fri, 2004-05-21 at 03:30, Emilio Ugo GIUFFRIDA wrote:
> It seems that gdb tries to read at 0xffffffff and, for pointers to 
> unsigned char, displays by default the string pointed.
> 
> Do you know if there is a gdb option disabling this behaviour?

I'm sure there is a way, but for the life of me, I cannot recall/find what
it is. Hopefully another reader out there remembers.

> Where is the point, in the code, where the gui tells the gdb to read 
> the local variables?

The variable stuff is all called from a gdb module called "varobj" (short
for variable objects). The actual updating of the variables happens in
VarTree::update_var:

    if {[catch {$var value} value]} {
      set color $colors(error)
    }

The first line asks the variable object to update itself. Eventually, this
will call varobj_update in src/gdb/varobj.c. You could set a break on this
function in gdb and step through it.

Hint: It sounds like you have a reproducible test case. Here's what I would
do. Get to the place in your program where you are ready to print "pt1".
Enter this variable into the watch window. This way, when varobj_update is
called, you don't have to filter through the twenty calls from the update of
all the local variables in the locals window.

That aside, two questions:
Do you have a stack backtrace for the crash?
What version of insight are you using? variables.tcl has been gone for quite
some time...

Keith

PS. Stupid thing to try: grab a newer version of varobj.c and drop it on top
of your older insight/gdb sources.