-var-create on invalid expression causes seg. fault

[Ross Morley <ross@tensilica.com>]

Hi,

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.

Here's the relevant code snippet from varobj_create():

  /* We definitively need to catch errors here.
     If evaluate_expression succeeds we got the value we wanted.
     But if it fails, we still go on with a call to evaluate_type()  */
  if (gdb_evaluate_expression (var->root->exp, &var->value))
    {
      /* no error */
      release_value (var->value);
      if (VALUE_LAZY (var->value))
    gdb_value_fetch_lazy (var->value);
    }
  else
    var->value = evaluate_type (var->root->exp);

  var->type = VALUE_TYPE (var->value);

gdb_evaluate_expression() fails, and GDB goes on to call
evaluate_type(). I don't think simply clearing var->value
is correct. Maybe release_value()? I don't have the time
to acquire enough knowledge of GDB varobj.

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.

Thanks for any insight.

---------------
Ross Morley
Tensilica, Inc.
ross@tensilica.com