Re: tracing ring_buffer_resize oops.

Re: tracing ring_buffer_resize oops.

[Steven Rostedt]

On Thu, 2012-05-24 at 16:05 -0400, Dave Jones wrote:
> On Thu, May 24, 2012 at 03:24:55PM -0400, Steven Rostedt wrote:
>  > On Thu, 2012-05-24 at 15:11 -0400, Dave Jones wrote:
>  > 
>  > >  > Also, how reproducible is it? When it triggered for me, it was constant.
>  > >  > Every boot and test failed. But after I did the make mrproper, I have
>  > >  > not been able to trigger it again. This is why I put it down as a bad
>  > >  > build.
>  > > 
>  > > happens every time for me so far.
>  > 
>  > Did you also do a make mrproper and try again?
> 
> ok, that's nasty.  Works fine after a make clean.
> 

Thanks for verifying. I'm thinking this is a build bug. Something's not
cleaning up properly. It may be with the recordmcount code. Perhaps
objects needed to change where the mcount calls are and did not?

I'll try other things to see if I can trigger this again. Then I'll save
off the build tree, do a make clean, rebuild, and compare what's
different.

-- Steve

Re: tracing ring_buffer_resize oops.

[Steven Rostedt]

On Thu, 2012-05-24 at 16:18 -0400, Steven Rostedt wrote:
> On Thu, 2012-05-24 at 16:05 -0400, Dave Jones wrote:
> > On Thu, May 24, 2012 at 03:24:55PM -0400, Steven Rostedt wrote:
> >  > On Thu, 2012-05-24 at 15:11 -0400, Dave Jones wrote:
> >  > 
> >  > >  > Also, how reproducible is it? When it triggered for me, it was constant.
> >  > >  > Every boot and test failed. But after I did the make mrproper, I have
> >  > >  > not been able to trigger it again. This is why I put it down as a bad
> >  > >  > build.
> >  > > 
> >  > > happens every time for me so far.
> >  > 
> >  > Did you also do a make mrproper and try again?
> > 
> > ok, that's nasty.  Works fine after a make clean.
> > 
> 
> Thanks for verifying. I'm thinking this is a build bug. Something's not
> cleaning up properly. It may be with the recordmcount code. Perhaps
> objects needed to change where the mcount calls are and did not?
> 
> I'll try other things to see if I can trigger this again. Then I'll save
> off the build tree, do a make clean, rebuild, and compare what's
> different.
> 

I'm kicking off the ktest that initially caused this issue hoping that
it reproduces the bad tree again.

BTW, did you happen to upgrade gcc or anything? The ktest I run does
test against different gcc's and I don't think I had it do a make clean
between the switch. That may be the cause of this problem too :-?

-- Steve

Re: tracing ring_buffer_resize oops.

[Dave Jones]

On Thu, May 24, 2012 at 04:33:06PM -0400, Steven Rostedt wrote:

 > I'm kicking off the ktest that initially caused this issue hoping that
 > it reproduces the bad tree again.
 > 
 > BTW, did you happen to upgrade gcc or anything? The ktest I run does
 > test against different gcc's and I don't think I had it do a make clean
 > between the switch. That may be the cause of this problem too :-?

No gcc updates. It's a Fedora 17 box, so there's been hardly any updates this
last week or so as things have been frozen leading into the release.

	Dave

Re: tracing ring_buffer_resize oops.

[Steven Rostedt]

On Thu, 2012-05-24 at 17:15 -0400, Dave Jones wrote:
> On Thu, May 24, 2012 at 04:33:06PM -0400, Steven Rostedt wrote:
> 
>  > I'm kicking off the ktest that initially caused this issue hoping that
>  > it reproduces the bad tree again.
>  > 
>  > BTW, did you happen to upgrade gcc or anything? The ktest I run does
>  > test against different gcc's and I don't think I had it do a make clean
>  > between the switch. That may be the cause of this problem too :-?
> 
> No gcc updates. It's a Fedora 17 box, so there's been hardly any updates this
> last week or so as things have been frozen leading into the release.
> 

I'm currently running a ktest that is similar to what I think I ran when
the bug hit (I didn't save off the config file :-(  )

But it looks like it did do a mrproper between switching gcc's so I no
longer think that was the issue.

Thanks,

-- Steve