[Win32] testprogs/TESTrun #1466
Comments
|
Update: guessing a But far too many |
|
Thank you for trying the script, I do not use Windows so never tested it in this context. I am working on a couple improvements, let me see if adding a proper help screen could be done in the same go. |
|
|
I have it as |
No, but there is
It should be Similar for |
|
In the current master branch the script now implements |
My my $re_define_uint = qr/^[[:blank:]]+#define[[:blank:]]+([0-9_A-Z]+)[[:blank:]]+([0-9]+)$/;
my $re_define_str = qr/^[[:blank:]]+#define[[:blank:]]+([0-9_A-Z]+)[[:blank:]]+"(.+)"$/;And is there a log-file with a summary generated? |
|
Seems all the TESTrun script failures were caused by me having which AFAICS does these: Why does these fail with It would be nice to have a |
Yes, that produces a lot of filter compiler debugging output, which will screw up comparisons of compiler output.
Does the output for filter-compiler failures show a diff between what was expected and what was produced? If not, it should be made to do so, just as the tcpdump dissection tests do. |
Not sure. I get this: So this hellish Perl-script does not match any |
|
Thank you for testing. The purpose of the timeout is to detect performance regressions. I understand rather than Then the latest revision should be able to parse that as well. Also the latest revision will refuse to run if Please test this version and post the results. |
|
For clarity, "no filtertest error" followed by some text means that the test expects a specific invalid combination of parameters in a specific environment to make |
The latest commits still shows 8 failures and some My and the results: run-filtertest-result.txt |
It's a DOS vs. Unix EOL issue. If I do: the test passes. Yikes! |
|
Thank you for testing, let me see what can be done quickly. |
Gisle Vanem in GH the-tcpdump-group#1466 comments that sometimes it is useful to see an explicit list of all passed tests. In this case perhaps it would also be useful to see how long each of those took to complete, in order to decide what timeout value to set. To implement that, introduce a new time_test_command() subroutine and the command-line option to control it through a global variable. In run_reject_test() and validate_stdout_test() use the new subroutine and on success pass any timing details about the test to result_passed(). Extend the latter to return that to test_and_report(); there print a table of passed tests details if available, but do not expect any details to be present in every case.
Gisle Vanem in GH the-tcpdump-group#1466 further comments that config.h may be using DOS newlines, also that the script is not a C preprocessor and its interpretation of config.h sometimes requires verification, so provide an easy way to see what it managed to parse. Return the hash from read_config_h() and in TESTrun print the contents if the user specifies the command-line option. This also makes it easy to notice that the hash initialization in read_config_h() isn't correct, which adds stray data into the result, make that right. Fix the quoted string matching regexp to match empty strings (i.e. PACKAGE_URL) and merge the two regexps into a more readable multiline extended one that disregards any stray CR/LF characters. Read strings together with the quotes because this way the output of --config looks more consistent with config.h and the regexp is much simpler.
Gisle Vanem in GH the-tcpdump-group#1466 comments that sometimes it is useful to see an explicit list of all passed tests. In this case perhaps it would also be useful to see how long each of those took to complete, in order to decide what timeout value to set. To implement that, introduce a new time_test_command() subroutine and the command-line option to control it through a global variable. In run_reject_test() and validate_stdout_test() use the new subroutine and on success pass any timing details about the test to result_passed(). Extend the latter to return that to test_and_report(); there print a table of passed tests details if available, but do not expect any details to be present in every case.
Gisle Vanem in GH the-tcpdump-group#1466 further comments that config.h may be using DOS newlines, also that the script is not a C preprocessor and its interpretation of config.h sometimes requires verification, so provide an easy way to see what it managed to parse. Return the hash from read_config_h() and in TESTrun print the contents if the user specifies the command-line option. This also makes it easy to notice that the hash initialization in read_config_h() isn't correct, which adds stray data into the result, make that right. Fix the quoted string matching regexp to match empty strings (i.e. PACKAGE_URL) and merge the two regexps into a more readable multiline extended one that disregards any stray CR/LF characters. Read strings together with the quotes because this way the output of --config looks more consistent with config.h and the regexp is much simpler.
Gisle Vanem in GH the-tcpdump-group#1466 comments that sometimes it is useful to see an explicit list of all passed tests. In this case perhaps it would also be useful to see how long each of those took to complete, in order to decide what timeout value to set. To implement that, introduce a new time_test_command() subroutine and the command-line option to control it through a global variable. In run_reject_test() and validate_stdout_test() use the new subroutine and on success pass any timing details about the test to result_passed(). Extend the latter to return that to test_and_report(); there print a table of passed tests details if available, but do not expect any details to be present in every case.
Gisle Vanem in GH the-tcpdump-group#1466 further comments that config.h may be using DOS newlines, also that the script is not a C preprocessor and its interpretation of config.h sometimes requires verification, so provide an easy way to see what it managed to parse. Return the hash from read_config_h() and in TESTrun print the contents if the user specifies the command-line option. This also makes it easy to notice that the hash initialization in read_config_h() isn't correct, which adds stray data into the result, make that right. Fix the quoted string matching regexp to match empty strings (i.e. PACKAGE_URL) and merge the two regexps into a more readable multiline extended one that disregards any stray CR/LF characters. Read strings together with the quotes because this way the output of --config looks more consistent with config.h and the regexp is much simpler.
Gisle Vanem in GH the-tcpdump-group#1466 comments that sometimes it is useful to see an explicit list of all passed tests. In this case perhaps it would also be useful to see how long each of those took to complete, in order to decide what timeout value to set. To implement that, introduce a new time_test_command() subroutine, which returns the exit status code and possibly the duration if the user requested it through the new command-line option. In run_reject_test() and validate_stdout_test() use the new subroutine and for passed tests feed the duration, if available, to result_passed(). Extend the latter to return the duration to test_and_report(); there print a table of passed tests details if available, but do not expect any details to be present in every case. Add T min/avg/max to the final statistics.
Gisle Vanem in GH the-tcpdump-group#1466 further comments that config.h may be using DOS newlines, also that the script is not a C preprocessor and its interpretation of config.h sometimes requires verification, so provide an easy way to see what it managed to parse. Return the hash from read_config_h() and in TESTrun print the contents if the user specifies the command-line option. This also makes it easy to notice that the hash initialization in read_config_h() isn't correct, which adds stray data into the result, make that right. Fix the quoted string matching regexp to match empty strings (i.e. PACKAGE_URL) and merge the two regexps into a more readable multiline extended one that disregards any stray CR/LF characters. Read strings together with the quotes because this way the output of --config looks more consistent with config.h and the regexp is much simpler.
|
Almost there. |
|
This failed test from you earlier comment looks odd: The filter program is from Other than that, there is a new revision of the script is in the master branch, it changes the means to use a custom Perl binary (set the The script now supports Let me know if you see any other bugs. |
|
Seems OK now: But I'd wish --- a/pcap/namedb.h 2025-02-16 16:50:41
+++ b/pcap/namedb.h 2025-02-18 11:46:49
@@ -56,6 +56,12 @@
u_char addr[6];
char name[122];
};
+
+#ifdef _WIN32
+ PCAP_API const char *pcap_etc_subpath (const char *file);
+ #define PCAP_ETHERS_FILE pcap_etc_subpath("ethers")
+#endif
+
#ifndef PCAP_ETHERS_FILE
#ifdef __HAIKU__
#define PCAP_ETHERS_FILE "/boot/system/settings/network/ethers"
@@ -99,6 +105,28 @@
PCAP_AVAILABLE_0_9
PCAP_API int pcap_nametollc(const char *);
+PCAP_API struct servent *pcap_getservent (void);
+PCAP_API void pcap_setservent (int f);
+PCAP_API void pcap_endservent (void);
+
+PCAP_API struct netent *pcap_getnetent (void);
+PCAP_API void pcap_setnetent (int f);
+PCAP_API void pcap_endnetent (void);
+
+PCAP_API struct netent *pcap_getnetbyname (const char *name);
+
+#if !defined(LIBPCAP_NO_EXTRAS)
+ #define getservent() pcap_getservent()
+ #define setservent(f) pcap_setservent(f)
+ #define endservent() pcap_endservent()
+
+ #define getnetent() pcap_getnetent()
+ #define setnetent(f) pcap_setnetent(f)
+ #define endnetent() pcap_endnetent()
+
+ #define getnetbyname(name) pcap_getnetbyname (name)
+#endif
+
/*
* If a protocol is unknown, PROTO_UNDEF is returned.
* Also, pcap_nametoport() returns the protocol along with the port number.The missing stuff for |
|
Thank you for preparing these changes, I see your point, but API changes such as these would need to be a separate pull request, could you open one please? Regarding the test script, could you describe the steps to get a working test setup for libpcap on Windows? I understand there is a practicable way to have |
|
Is this true that if you add an entry to the |
|
AppVeyor build includes both testprogs and Perl, so after this round of improvements |
Added this to and ran: and: So, yes. |
I'm clumsy wrt to
I have installed Cygwin64 from https://cygwin.org/setup-x86_64.exe, ran the setup and added |
|
Thank you. The above filter program is IPv4-only. Apparently, Windows uses a slightly different format for the file, and link-local IPv6 address must use a zone ID, which would be an unnecessary complication for the tests. Before I change the test address and start updating the tests, could you retry using |
You mean, replace Seems to work: but why so many more op-codes? I also added |
|
Because now the filter program tests for both IPv4 and IPv6, which is the correct behaviour of |
|
Please get the latest revision, update the |
|
I did a to my But still The perl first used reports itself as |
|
Please copy the lines from the Perl script exactly (with one space between the address and the name) and retry. |
No difference; still |
|
Possibly the difference between DOS and Unix newlines gets in the way of the file verification function. Let me see how to address this. |
|
Does this change resolve the newlines issue? --- a/testprogs/TESTrun
+++ b/testprogs/TESTrun
@@ -162,7 +162,7 @@ sub skip_unless_file_contains_lines {
open FH, '<', $filename or return $skip;
while (<FH>) {
- chomp;
+ s/[\r\n]*$//o; # chomp() removes LF, but not CR, even on Windows.
next unless exists $notfound{$_};
delete $notfound{$_};
last unless scalar keys %notfound;Do you get the same results using "msys" and "MSWin32" varieties of Perl? |
|
Yes. Better: |
|
Thank you for confirming. So, are "MSWin32" and "msys" the same for the purposes of this script? |
I have no Perl new enough with |
|
Thank you for clarifying. I am going to use only |
There are other Perls for Windows; I have Strawberry Perl 5.18.4 which do not work for I feel Perl is a diabolic language ( |
|
Switching to Python is a sound potential future improvement, but not the only that requires attention right now. |
|
Commit 5019d5c makes the discussed changes to the Perl code, so my work on this case looks done. Thank you for all the testing and feedback! There is a proposed Windows-specific patch in the comments, I have no means to review or to test it, it should be done by someone familiar with Windows development. Hence leaving the issue open. |
|
Forgot to mention: the value of |
Trying
testprogs/TESTrunon Windows, like this (in a home-grown GNU-makefile):Does this make sense?
The output of
make run_filtertestsis:What does all these letters mean? AFAICS,
TESTrunaccepts no-hor--help. Would be nice.But more importantly, why only
2 tests passed, but sometimes 5 (and which are those?).No .log-files left over AFAICS to give me a clue.
The text was updated successfully, but these errors were encountered: