Powered by Linux
Re: Regression in Smatch — Semantic Matching Tool

Re: Regression in Smatch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 12, 2014 at 09:13:26PM -0600, Larry Finger wrote:
> On 02/12/2014 05:51 PM, Dan Carpenter wrote:
> >On Wed, Feb 12, 2014 at 03:57:34PM -0600, Larry Finger wrote:
> >>Dan,
> >>
> >>As my version of Smatch did not show some of the warnings that you
> >>reported to me earlier, I did a git pull and ran into a regression
> >>that causes Smatch to run very slowly, and may have an infinite
> >>loop. I bisected the problem and got the following:
> >>
> >>Commit		Execution time
> >>2c45218		35 sec
> >>3ef1e73 	4 min 43 sec
> >>d94be05		Not finished after 1 hour
> >>
> >>Those are sequential commits. All of these were run on an otherwise
> >>unloaded system on the current code in drivers/staging/rtl8188eu/.
> >>The command used was
> >>
> >>time make CHECK=~/smatch/smatch C=2 drivers/staging/rtl8188eu/
> >>
> >>As you see, make used only a single CPU. None of the files needed to
> >>be compiled.
> >>
> >>I will be happy to test any fixes. For the moment, I am sticking
> >>with commit 2c45218.
> >
> >On my system there are 2 files which take 6 minutes to process, so 12
> >minutes total if you are building on 1 CPU.  Six minutes is sort of long
> >but it's endurable.  How much RAM do you have?  Perhaps you are
> >swapping, I can add a work around if we're running out of memory.
> 
> I have 3 GB. I reran the test with "make -j2" and got the following:
> 
> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:4403 rtw_dbg_port()
> Function too hairy.  Giving up.
> 
> real    135m8.081s
> user    220m11.645s
> sys     1m55.307s
> 
> This time I was watching top while it ran. One of the routines that
> finished used ~80 min. The one that failed had used about 45 min,
> and it had a virtual memory footprint of 1.5 GB.
> 
> These times are not really endurable.
> 

Yes, of course.  The "Function too hairy." thing is supposed to be a
safety cut-out.  I should add a time limit so if a single function goes
over 5 minutes then it's too hairy.

But I also should go through the memcpy() changes to see if there is a
better fix.

I'll take a look.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux