Re: Problem with unsigned char* data

[Keith Seitz <keiths at redhat dot com>]

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.