Page MenuHomeFreeBSD

Fix sys.kern.coredump_phnum_test.coredump_phnum on i386
ClosedPublic

Authored by ngie on Apr 22 2019, 10:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 19, 8:02 AM
Unknown Object (File)
Mar 20 2024, 12:45 AM
Unknown Object (File)
Feb 21 2024, 2:17 PM
Unknown Object (File)
Jan 29 2024, 4:15 PM
Unknown Object (File)
Jan 14 2024, 5:21 AM
Unknown Object (File)
Jan 5 2024, 1:55 PM
Unknown Object (File)
Jan 5 2024, 1:55 PM
Unknown Object (File)
Jan 5 2024, 1:55 PM
Subscribers

Details

Summary

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

Test Plan

Tested the change on ^/head (amd64) and ^/stable/12 (i386).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Apr 22 2019, 11:13 AM

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.

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.

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*).

This revision was automatically updated to reflect the committed changes.
In D20005#429915, @ngie wrote:

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.

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*).

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.

In D20005#430003, @cem wrote:

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).

Hmmm... good to know. I guess it would help if I had read the comments >_> (thank you for pointing that out!)...

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.

Np!