Do not unset local array variable in Bash func #47
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Do not unset local array variable to clear it in "get_module_verinfo"
function in "dkms" script. Assign empty array instead.
When a local variable is "unset" in Bash, it is completely removed, and
its scope is lost. If a new value is assigned to the same name
afterwards (and there was no local variable with the same name up the
stack), a new variable is created, this time with the global scope.
If then a local variable is created with the same name again, it hides
the global one, and if that is "unset" again, the global one becomes
visible again.
This is what happens with the "check_version_sanity" and
"get_module_verinfo" functions in "dkms" script. It works OK, if both
kernel and installed module have version info, but when there is more
than one module to process, and a second or later in-kernel module
("$kernels_module") lacks any version info in the kernel, the
"check_version_sanity" function uses the last built module's version
info instead.
I.e. this is how "check_version_sanity" would work for a module with
version information in both kernel and dkms build:
This is how "check_version_sanity" would work for a module without
version information in the kernel, but with version information in the
module being installed
And for a second invocation of "check_version_sanity" for a similar
module:
This was hit while testing installation of digimend-dkms-7 .deb package on
Debian Stable with DKMS v2.2.1.0. The installed kernel's module didn't have
version info, the modules being installed did, and the second module failed to
update, as DKMS thought in-kernel module version was the same (being taken
from the previous module being installed, which had the same version).
Sample output: