(Another) Segfault in varobj.c

(Another) Segfault in varobj.c

[Robert Norton]

Hi,

I have encountered another crash seemingly originating in varobj.c.
Whilst I've been able to work around the segfault I think there are some
deeper rooted problems and I remembered from our previous conversation
that the whole of this has been rewritten for 6.7. How self contained
were these changes, i.e. would it be hard to back port them for our 6.6
based release? How risky would this be?

Thanks,

Robert

Re: (Another) Segfault in varobj.c

[Nick Roberts]

 > I have encountered another crash seemingly originating in varobj.c.
 > Whilst I've been able to work around the segfault I think there are some
 > deeper rooted problems and I remembered from our previous conversation
 > that the whole of this has been rewritten for 6.7. How self contained
 > were these changes, i.e. would it be hard to back port them for our 6.6
 > based release? How risky would this be?

I can't say how risky it would be, I don't even understand why you would rather
backport to 6.6 than update to 6.7.  If you do need to be selective about the
changes, I would just suggest including those from mi-cmd-var.c/h too.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: (Another) Segfault in varobj.c

[Vladimir Prus]

Robert Norton wrote:

> Hi,
> 
> I have encountered another crash seemingly originating in varobj.c.
> Whilst I've been able to work around the segfault I think there are some
> deeper rooted problems and I remembered from our previous conversation
> that the whole of this has been rewritten for 6.7. How self contained
> were these changes, i.e. would it be hard to back port them for our 6.6
> based release? How risky would this be?

It's hard to say without knowing if you have any local changes in varobj.c
If not, then just grabbing varobj.c and maybe mi/* should be safe --
at least as far as my patches are concerned, they are local to varobj.c.

- Volodya

RE: (Another) Segfault in varobj.c

[Robert Norton]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> Sent: 07 August 2007 16:09
> To: gdb@sources.redhat.com
> Subject: Re: (Another) Segfault in varobj.c
>
> It's hard to say without knowing if you have any local 
> changes in varobj.c

Only an attempt to fix another bug which apparently is fixed in CVS
anyway.

> If not, then just grabbing varobj.c and maybe mi/* should be safe --
> at least as far as my patches are concerned, they are local 
> to varobj.c.

OK. This is mostly what I wanted to know. I'll give it a try!

Robert

RE: (Another) Segfault in varobj.c

[Robert Norton]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Robert Norton
> Sent: 07 August 2007 17:11
> To: Vladimir Prus; gdb@sources.redhat.com
> Subject: RE: (Another) Segfault in varobj.c
>
> I'll give it a try!

For anyone who's interested I managed to back port the changes by
copying varobj.c/h and mi/*. I had to edit mi-main.c to get it to
compile (used current_regcache instead of get_current_regcache()) and
also had to add a call to varobj_invalidate() in symfile.c.

I also had a problem with one of the tests: mi-var-cmd.exp creates a
varobj from a char* but due to gdb interpreting it is a null terminated
string it appears to be modified even though it is actually the llong
variable which is allocated after it in memory which has changed. What's
needed is some way to tell gdb that lpcharacter really is just a char *
(not a pointer to a null terminated string).

Robert

Re: (Another) Segfault in varobj.c

[Daniel Jacobowitz]

On Wed, Aug 08, 2007 at 10:59:56AM -0700, Robert Norton wrote:
> I also had a problem with one of the tests: mi-var-cmd.exp creates a
> varobj from a char* but due to gdb interpreting it is a null terminated
> string it appears to be modified even though it is actually the llong
> variable which is allocated after it in memory which has changed. What's
> needed is some way to tell gdb that lpcharacter really is just a char *
> (not a pointer to a null terminated string).

Or not to treat it as a string (I have some posted work in that area)
or just to NUL terminate it...

-- 
Daniel Jacobowitz
CodeSourcery