Bugs/Features

Bugs/Features

[Willem Hajenius]

To the developers of the Cygnus Insight Debugger v5.0,

Your visual debugger is my all-time favorite! I use it in conjunction
with Dev-C++ and it performs excellent! However, I've found the following
bugs/remarks in your product that should deserve some attention:

* Please provide a window similar to the "Source is more recent than
executable"-dialog, with a "Don't show this in the future"-checkbox,
and an Preference setting to enable all disabled messages. (This is
often forgotten; as a consequence users become fearful to dismiss a dialog
'forever'.)

* The checkbox mentioned above doesn't work: the dialog keeps popping up
in future sessions.

* Also make the "i386 Architecture file may be incompatible with i386:intel
target"-message box dismissable. After hundreds of debugging sessions it
becomes
very annoying.

* Add a Preference option to completely expand or contract the compound
variables
in the Local Variables-window. This would prove very time-saving,
particularly
with complex data structures.

* (Not quite sure about the exact cause of this one) It appears that when
an array is (re)alloc'ed, it's representation in the Local Variables-window
is not updated. Consider the following code snippet:

struct rec
{
  char c[5];
};

typedef struct rec foo;

int main()
{
  foo* f;
  f = (foo*) malloc (10);
  f->c[9] = 'A';
  free (f);
  return 0;
}

This works perfectly well, yet the Local Variables-window doesn't indicate
that
'c' is now 10 characters large.


Please think about these issues.


Kind regards,

Alexander Hajenius.

Re: Bugs/Features

[Keith Seitz]

On Thu, 13 Sep 2001, Willem Hajenius wrote:

> * Please provide a window similar to the "Source is more recent than
> executable"-dialog, with a "Don't show this in the future"-checkbox,
> and an Preference setting to enable all disabled messages. (This is
> often forgotten; as a consequence users become fearful to dismiss a dialog
> 'forever'.)
>
> * The checkbox mentioned above doesn't work: the dialog keeps popping up
> in future sessions.

Unfortunately, as you've discovered, the "dismissable" warnings are
renewed every time Insight is run. I think that I can fix this easily
enough, though, but it hints at more inadequacies in the preferences code.
(For example, almost all warning generated by core gdb are not
dismissable.) I have given this some thought, and I think that I can
weasel my way around gdb to get something working (as ugly as it may be).

> * Also make the "i386 Architecture file may be incompatible with i386:intel
> target"-message box dismissable. After hundreds of debugging sessions it
> becomes very annoying.

I have no idea what this is: it is certainly a message from the bowels of
the debugger which alludes to a more serious problem. You might inquire on
the gdb list (gdb@sources.redhat.com) how to get rid of this warning.

> * Add a Preference option to completely expand or contract the compound
> variables in the Local Variables-window. This would prove very
> time-saving, particularly with complex data structures.

We could provide something like this, but we cannot expand *all* levels,
obviously. We could have a preference to set some limit on how many levels
are expanded, though. I would need to give some very serious thought to
the utility of this feature, though. I can imagine defining some sort of
template to be used whenever a specific type shows up in the window,
though. For example, I could see that it would be very convenient to have
a way to tell the variable window that any "struct foo" be expanded
automatically in the window.

I'll jot this down as a feature to investigate when it comes time to
rewrite the locals and watch windows. (This is one of my highest
priorities with Insight, btw.)

> * (Not quite sure about the exact cause of this one) It appears that when
> an array is (re)alloc'ed, it's representation in the Local Variables-window
> is not updated. Consider the following code snippet:
>
> struct rec
> {
>   char c[5];
> };
>
> typedef struct rec foo;
>
> int main()
> {
>   foo* f;
>   f = (foo*) malloc (10);
>   f->c[9] = 'A';
>   free (f);
>   return 0;
> }
>
> This works perfectly well, yet the Local Variables-window doesn't indicate
> that 'c' is now 10 characters large.

(I must say -- this is an evil coding practice! Why hide the true type of
the variable? If you want to make it opaque, just make it opaque and
cast it when needed. Maybe this is just a bad example??)

I think I see what you mean, but what you are asking is not possible with
ANY debugger that I've ever used. What you've written is very sneaky code,
and the compiler does NOT generate data telling the debugger that you've
done this.

All the debugger knows about is a structure with an array "c" of five
bytes. It _cannot_ ever change this definition on the fly. C/C++
are languages where, for example, "struct rec" will ALWAYS contain a
single five-element character array within main: you cannot willy-nilly
change its type, although you can (and have) "worked around" this in the
example above.

That being said, there is still hope. One of the features being planned
for the new variable windows is a "view as" operator, which will allow the
user to change the view type of a variable on the fly.

Think of the code like this:

struct rec
  {
     char c[5];
  };
typedef struct rec foo;

struct _rec
  {
    char c[9];
  };

int main()
{
  foo* f;
  struct _rec *r;

  f = (foo*) malloc (sizeof (struct _rec));
  r = (struct _rec *) f;
  r->c[9] = 'A';
  free (f);
  return 0;
}

Thus, as long as define a real type in your program, you will be able to
view "f" as this type. You can do this in the currect watch window by
entering the cast in the window at the bottom, i.e., enter "(struct _rec *)f".

I thank you for your suggestions and kind words!
Keith

Re: Bugs/Features

[Tom Tromey]

Keith> Unfortunately, as you've discovered, the "dismissable" warnings
Keith> are renewed every time Insight is run.

I think there's a PR for this.

>> struct rec
>> {
>> char c[5];
>> };
>> 
>> f = (foo*) malloc (10);

Keith> (I must say -- this is an evil coding practice! Why hide the
Keith> true type of the variable? If you want to make it opaque, just
Keith> make it opaque and cast it when needed. Maybe this is just a
Keith> bad example??)

Actually this is the old C `struct hack' idiom.  In traditional C you
were allowed to declare the last field in a struct as an array; then
you could allocate additional space and it would act like a
variable-sized array, without the overhead of an additional pointer in
the struct.

It isn't very common, but it isn't uncommon either.

Tom