On Tue, Aug 09, 2005 at 11:29:31AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 9 Aug 2005, Peter Hagervall wrote:
> >
> > Yes, assuming c8b9ce8f1ef27a0e77c87ea1581c6e2b33753e7a is the current
> > HEAD. My arch is x86. 
> 
> Yup, that's what I tested too.
> 
> > The straightforward way of using it is just prepending the command line
> > with 'valgrind', so in this case I have:
> 
> I just get "missing --tool option" from that.
> 
> I did a "valgrind --tool=memcheck" thing, and yes, I see two invalid reads
> in clean_up_insns too.
> 
> I suspect that valgrind could find better errors if it was told about 
> "allocate()" and "free_one_entry()". As it is, it won't notice any normal 
> allocation mis-use, because it just sees them as one mmap. The 
> clean_up_insns one seems to be from some of the (rare) malloc/free users, 
> namely the ptr_list allocations.
> 
> The fact that the pointer list that is warned about was free'd by
> "simplify_switch()" is interesting - that sure as hell is some very 
> special code. And valgrind did _not_ complain about kernel/sched.c, for 
> example, so it's certainly not a normal error.
> 
> > I'll try to track down the problem later tonight.
> 
> Thanks. I'll see if I get around to looking closer later too.
> 
>               Linus

I think I have it narrowed down a bit now, it seems that
ac8ce3636d83e25d8a316fdce221e36c04c02dc1 is OK, whereas its child,
972609f0d10e3bcb10a9132802b2edb8b01d305f is not.

valgrind still complains about invalid reads in clean_up_insns, but at
least it doesn't segfault.

--
Peter Hagervall
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to