[gvd-devel] gvd problems...

Toralf Lund toralf@kscanners.com
Fri, 13 Jul 2001 14:20:26 +0200


Emmanuel Briot wrote:

>  > I just downloaded and installed gvd (via gvd-1.2.0-1.i386.rpm), and it
>  > certainly looks very promising indeed, but I'm having some problems that
>  > rather limits in usefulness right now. In particular, it seems unable to
>  > inspect core files. At least, I won't get anything in the stack trace
>  > window when I start with core as 2nd argument or open it via "Open core
>  > dump", when the same works just fine with ddd.
>
> Try typing "core core" in the command window at the bottom of the gvd screen,
> and see if it improves things.

> I can't remember right now whether we
> implemented the "open core file" on all platforms.
> If the problem isn't in opening the core file, it might be because we do not
> send a proper refresh command to the backtrace window. Maybe you can try to
> hide it and show it again.

I tried these and several other tricks, but nothing seemed to help. What did work,
however, was to start the application, exit in a controlled manner, then open the
core file. So I guess the problem is really that the symbol table isn't read or
something like that.

> Or you might want to always run your program inside gvd. It won't really slow
> it done (except for the loading part), and at least you'll be able to inspect
> everything when a crash occurs.

Yes, but programs also tend to crash from time to time in a real user environment,
and the problems aren't always easy to reproduce. Which is why the core dump
mechanism is so beautiful.

> Any information you can send will be helpful to fix gvd, if needed.

Also note that all our applications are linked with DSOs, and the particular one I
was testing with also loads a few of those in run-time (via dlopen()).

>  > Also, it would make a _LOT_ of difference to me if the if the source
>  > file pane would list C++ methods (this can't be hard to implement, it is
>  > just a matter of accepting slightly different conventions for function
>  > names.)
>
> We are primarily interested in Ada, on our side. We would gladly integrate any
> code that does the above, especially since it would indeed be very helpful for
> C++ developpers. However, we except contributions in this area. Any candidate ?
> Basically, this explorer is based on regular expressions, we are currently
> using the Emacs ones.

I might be able to look into this some time, when I get back from my holiday
perhaps...

>
>  > and is there really no way to search the source code?
>
> This is indeed not doable currently. However, we are working hard on a new
> improved version of the editor (that would actually permit editing), that will
> have this searching capabilities.
> This will not be available in the next version, since there a lot of other
> changes we need to stabilize first.
>
> Emmanuel

--
- Toralf