The zero-padding when printing out the Size field is 5, not 15. Adjust the
regular expression to work with both the 32-bit and non 32-bit case.
MFC after: 1 week
Differential D20005
Fix sys.kern.coredump_phnum_test.coredump_phnum on i386 ngie on Apr 22 2019, 10:14 AM. Authored by Tags None Referenced Files
Subscribers
Details The zero-padding when printing out the Size field is 5, not 15. Adjust the MFC after: 1 week Tested the change on ^/head (amd64) and ^/stable/12 (i386).
Diff Detail
Event TimelineComment Actions Thanks for the better fix. BTW, I still think these checks would be better to be rewritten as getting the real number and compare with 65535. Comment Actions Totally agree, but I couldn't get clarity on whether or not the value could be static or how to compute it. I'll see if I can reverse engineer how sometime in the future (*files bug*). Comment Actions It's not a static number, AFAICT, depending on how the kernel maps libraries or waves hands does stuff with virtual memory. Hence the sloppy 66xxx match. I think @lwhsu's proposal is something like atf_check [ "$num" -gt 65535 ], which verifies that the number exceeds the lower 16 bit limit (which is the coredump feature the regression test is attempting to verify). By the way, post-facto ๐ to this revision (Phabricator removes the "approve" option for closed Differentials). Thanks for fixing the test on 32-bit CI. Comment Actions Hmmm... good to know. I guess it would help if I had read the comments >_> (thank you for pointing that out!)...
Np! |