How to use --non_fatal option?

32 views
Skip to first unread message

Grégory Vander Schueren

unread,
Nov 18, 2016, 5:48:06 AM11/18/16
to packetdrill
Hello,

I would like to be able to write bogus syscalls (such as "0 socket(..., -42, IPPROTO_TCP) = -1 EINVAL (Invalid argument)") and have Packetdrill return an exit code of 0. Is it possible to achieve this?

I tried with the "--non_fatal=syscall" option but it returns an exit code 1 with the following output: "Expected non-negative result but got -1 with errno 22 (Invalid argument)”.

When I look at the source code, the --non_fatal options sets "config->non_fatal_syscall = true;" but this boolean seems to be never used in the rest of the code. How am I supposed to use this option?

Thank you,
Gregory

Neal Cardwell

unread,
Nov 18, 2016, 2:41:48 PM11/18/16
to Grégory Vander Schueren, packetdrill
On Fri, Nov 18, 2016 at 5:48 AM, Grégory Vander Schueren <gregory.van...@gmail.com> wrote:
Hello,

I would like to be able to write bogus syscalls (such as "0 socket(..., -42, IPPROTO_TCP) = -1 EINVAL (Invalid argument)") and have Packetdrill return an exit code of 0. Is it possible to achieve this?

I tried with the "--non_fatal=syscall" option but it returns an exit code 1 with the following output: "Expected non-negative result but got -1 with errno 22 (Invalid argument)”.

Yes, your syntax for the socket() call looks good to me.

It probably wasn't working because the public version of packetdrill did not yet support negative return codes from socket() or accept() or open(). We had a patch for that at Google, so I have applied that in the public github repo as well now:


Please pull the latest version of packetdrill and try that socket() call again. It should work this time. Please let me know if you run into any issues. 



When I look at the source code, the --non_fatal options sets "config->non_fatal_syscall = true;" but this boolean seems to be never used in the rest of the code. How am I supposed to use this option?

The option for non-fatal system calls is not implemented yet, as you discovered. :-) Only non-fatal handling of packet errors is supported so far.

Here is a summary of the --non_fatal=packet feature, based on paraphrasing from the commit description from Barath Raghavan, the author of that feature:

    When the command line argument --non_fatal=packet is given,
    packetdrill continues executing the script even after certain outbound
    packet assertions fail (those that do not indicate a more general failure).
    This enables multiple failed packet assertion outputs per test run. 
    
    There is also command-line parsing support for handling non-fatal failures
    of other types (currently for the 'syscall' type), but packetdrill does not
    currently support multiple non-fatal syscall assertion failures.
    Eventually, if implemented, this could allow for requesting that
    both packet and syscall assertions are non-fatal via:
    --non_fatal=packet,syscall.

Hope that helps,
neal

Michael Tüxen

unread,
Nov 20, 2016, 10:33:01 AM11/20/16
to Neal Cardwell, Grégory Vander Schueren, packetdrill

> On 18 Nov 2016, at 20:41, 'Neal Cardwell' via packetdrill <packe...@googlegroups.com> wrote:
>
> On Fri, Nov 18, 2016 at 5:48 AM, Grégory Vander Schueren <gregory.van...@gmail.com> wrote:
> Hello,
>
> I would like to be able to write bogus syscalls (such as "0 socket(..., -42, IPPROTO_TCP) = -1 EINVAL (Invalid argument)") and have Packetdrill return an exit code of 0. Is it possible to achieve this?
>
> I tried with the "--non_fatal=syscall" option but it returns an exit code 1 with the following output: "Expected non-negative result but got -1 with errno 22 (Invalid argument)”.
>
> Yes, your syntax for the socket() call looks good to me.
>
> It probably wasn't working because the public version of packetdrill did not yet support negative return codes from socket() or accept() or open(). We had a patch for that at Google, so I have applied that in the public github repo as well now:
>
> https://github.com/google/packetdrill/commit/47582211690ffc2a7f40c371c19d283b2df26a44
>
> Please pull the latest version of packetdrill and try that socket() call again. It should work this time. Please let me know if you run into any issues.
Hi Neal,

we had similar code in our fork, but I changed it to keep the difference at a minimum.

Please note that we have two additional changes in our fork within end_syscall:
https://github.com/nplab/packetdrill/blob/master/gtests/net/packetdrill/run_system_call.c#L1570

1. Only use strerror() if actual is negative. If actual is non-negative, it doesn't make sense
to look at actual_errno.

2. In case of actual_errno is different from expected_errno, you call strerror() twice as arguments
of the printf() function. This is not portable.

Best regards
Michael
>
>
>
> When I look at the source code, the --non_fatal options sets "config->non_fatal_syscall = true;" but this boolean seems to be never used in the rest of the code. How am I supposed to use this option?
>
> The option for non-fatal system calls is not implemented yet, as you discovered. :-) Only non-fatal handling of packet errors is supported so far.
>
> Here is a summary of the --non_fatal=packet feature, based on paraphrasing from the commit description from Barath Raghavan, the author of that feature:
>
> When the command line argument --non_fatal=packet is given,
> packetdrill continues executing the script even after certain outbound
> packet assertions fail (those that do not indicate a more general failure).
> This enables multiple failed packet assertion outputs per test run.
>
> There is also command-line parsing support for handling non-fatal failures
> of other types (currently for the 'syscall' type), but packetdrill does not
> currently support multiple non-fatal syscall assertion failures.
> Eventually, if implemented, this could allow for requesting that
> both packet and syscall assertions are non-fatal via:
> --non_fatal=packet,syscall.
>
> Hope that helps,
> neal
>
>
> --
> You received this message because you are subscribed to the Google Groups "packetdrill" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to packetdrill...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages