On Oct 11 2016, Julia Lawall <julia.law...@lip6.fr> wrote:
> On Mon, 10 Oct 2016, Nikolaus Rath wrote:
>
>> On Oct 10 2016, Julia Lawall <julia.law...@lip6.fr> wrote:
>> >> Ok, we're getting there. I've removed the second 'symbol' line, and
>> >> (permanently) updated to 1.0.6. However, now it seems to simply run
>> >> forever:
>> >>
>> >> $ ../coccinelle-1.0.6/spatch.opt --sp-file
>> >> ~/in-progress/libfuse/se-rename.cocci --in-place lib/ include/ test/
>> >> example/ util/
>> >> init_defs_builtins: /home/nikratio/tmp/coccinelle-1.0.6/standard.h
>> >> warning: patch output can only be created when only one
>> >> directory is specified or when the -patch flag is used
>> >> HANDLING: lib/fuse.c
>> >> (ONCE) Expected tokens fuse_session f
>> >> Skipping:lib/fuse_opt.c
>> >> HANDLING: lib/helper.c
>> >> Skipping:lib/mount_bsd.c
>> >> Skipping:lib/fuse_loop_mt.c
>> >> Skipping:lib/fuse_loop.c
>> >> HANDLING: lib/cuse_lowlevel.c
>> >> diff =
>> >> [...]
>> >> HANDLING: lib/fuse_lowlevel.c
>> >>
>> >> At this point it has been hanging for about 15 minutes now, steady
>> >> eating CPU time.
>> >>
>> >> Is it supposed to take that long? The fuse_lowlevel.c file is 74k with
>> >> 2465 lines of code.
>> >
>> > You can use --show-trying to see what function it is getting stuck on.  If
>> > the function has a lot of ifs and loops, it may indeed take a long
>> > time.  ... follows possible paths in the execution graph and a sequence of
>> > ifs makes the number of paths grow exponentially.
>> >
>> > A solution is to add a timeout, eg --timeout 120 (120 seconds).  You will
>> > need to check a file on which there is a timeout manually.
>> >
>> > Tracing paths around loops is not really relevant in your case, so you can
>> > also safely use the option --no-loops, which will avoid taking the back
>> > edges.
>>
>> I tried doing both, but it still gets stuck:
>>
>> init_defs_builtins: /home/nikratio/tmp/coccinelle-1.0.6/standard.h
>> HANDLING: lib/fuse_lowlevel.c
>> -----------------------------------------------------------------------
>> rule starting on line 1 =
>> -----------------------------------------------------------------------
>> [...]
>> -----------------------------------------------------------------------
>> rule starting on line 13 =
>> -----------------------------------------------------------------------
>> [...]
>>    trying function: do_init: fuse_lowlevel.c:1812
>>
>>
>> The do_init() function doesn't seem all that terrible to me though:
>> https://github.com/libfuse/libfuse/blob/58273972f0b20/lib/fuse_lowlevel.c#L1812
>
> Yes it does.  Look at lines 1852-1877.  There are 2^13 execution paths
> there, and there is another such stack of ifs later in the function.
>
> So you did add a timeout and it is still getting stuck?  Try a very short
> timeout just to see what happens.

Sorry for the confusion. No, when I add the timeout then it aborts. But
I thought that with --no-loops it would not trace out all the different
paths and should complete more quickly.

Also, it seems that with --timeout it aborts completely (instead of just
going to the next function):

     trying function: do_fallocate: fuse_lowlevel.c:1798
     trying function: do_init: fuse_lowlevel.c:1812
timeout (we abort)
Fatal error: exception Common.Timeout

$

Is that intended?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Reply via email to