Re: -var-create on invalid expression causes seg. fault

[Nick Roberts <nickrob@snap.net.nz>]

> One of our customers reported GDB crashing when an MI
> variable is created on an invalid address and then referenced.
> I've debugged to the point of finding the cause, but am not
> knowledgable enough on the MI variables to know the right
> way to fix it. I filed a bug report because this needs
> to get fixed in the latest sources. I'd appreciate any
> insight so I can fix it in our 5.2.1 based sources.
> I don't have the time to look deeper, but someone on this
> list is familiar with this stuff I'm sure.


> -var-create on an expression that's invalid (eg. "(*1)")
> creates a variable and retains a ptr in var->value. That
> gets freed by free_all_values() next command. Later a
> -var-update or -var-evaluate-expression on that variable
> dereferences the freed memory, causing a seg. fault.

Since you have 5.2.1 based sources, you could run it under gdb and the
backtrace should show you where the problem occurs e.g. in the directory of
your source, somthing like:

/usr/bin/gdb ./gdb
...
(top-gdb) cd ~/
(top-gdb) run -i=mi myprog
...
(gdb)
-var-create - * *1
&"Cannot access memory at address 0x1\n"
^done,name="var1",numchild="0",type="int"
(gdb) 
-var-update *
&"Cannot access memory at address 0x1\n"
Segmentation fault
(top-gdb) bt
...

> I looked at the GDB 6.3 source and it seems to be the same.

> Now why would anyone try to evaluate *1? It's some tool that
> uses MI, one of our customers reported. I'm not clear on why
> GDB even creates the variable in this case, but it does.
> GDB should report an error, not crash.

GDB in CVS doesn't crash although it does allow a variable object to be set at
a nonsensical address. Perhaps this behaviour should be changed. However, I
don't think people on this list will be generally interested in debugging old
versions of GDB.


Nick