Closed kbara closed 9 years ago
It seems that it is indeed an optimizer bug:
wingo@rusty:~/src/pflua$ ./env tools/pipe-lua-libpcap-match tests/data/arp.pcap 'icmp or arp' 2
BUG: pure-lua false, bpf-lua true, libpcap true.
wingo@rusty:~/src/pflua$ ./env tools/pipe-lua-libpcap-match -O0 tests/data/arp.pcap 'icmp or arp' 2
OK: pure-lua, bfp-lua, and libpcap pipelines matched: all true
Kat's tests passed -O0 to luajit :) Funny bug. I guess the lesson is to always use the env scripts.
Oops. :-)
The root cause was indeed the length hoisting bug, which is now fixed: https://github.com/Igalia/pflua/issues/182 for details.
I'm closing this bug, as we appear to not have any more low-hanging "x or y" bugs, where x and y are protocol names. See https://github.com/Igalia/pflua/pull/183 for details.
while ../tools/pflua-quickcheck properties/pipecmp_proto_or_proto ../tests/data/arp.pcap; do; done
and
while ../tools/pflua-quickcheck properties/pipecmp_proto_or_proto ../tests/data/wingolog.pcap; do; done
are both turning up no counter-examples.
https://github.com/Igalia/pflua/issues/178 mentioned incorrect behaviour with an "icmp or arp" filter. Here is some work towards narrowing down the problem.
The behaviour is packet-dependent. % luajit ./pipe-lua-libpcap-match ../tests/data/arp.pcap "icmp or arp" 1 OK: pure-lua, bfp-lua, and libpcap pipelines matched: all true % luajit ./pipe-lua-libpcap-match ../tests/data/arp.pcap "icmp or arp" 2 BUG: pure-lua false, bpf-lua true, libpcap true.
This falsifies the idea that it's purely due to protocol assertions.
The bug persists with optimization disabled. % luajit -O0 ./pipe-lua-libpcap-match ../tests/data/arp.pcap "icmp or arp" 2 BUG: pure-lua false, bpf-lua true, libpcap true.
This falsifies the idea that it's purely an optimizer bug.