Description of problem: gdisk relies on popt leaking memory and preserving leftover arguments in a context over poptResetContext(), possibly other places too. This leak is fixed in popt 1.19 but that will break gdisk. Version-Release number of selected component (if applicable): At least gdisk 1.0.9 How reproducible: Always Steps to Reproduce: 1. sgdisk -p /dev/notthere (this is a silly example of course but I needed something non-destructive etc, this applies to every single command) Actual results: Problem opening =��V for reading! Error is 2. The specified file does not exist! Expected results: Problem opening /dev/notthere for reading! Error is 2. Additional info: Something like this will fix the poptGetArg() issue above. I don't know if this is the only problem in there - when there's one there's often more. --- gptfdisk-1.0.9/gptcl.cc.orig 2022-06-23 11:59:55.580514088 +0300 +++ gptfdisk-1.0.9/gptcl.cc 2022-06-23 12:01:03.980023728 +0300 @@ -155,7 +155,7 @@ int GPTDataCL::DoOptions(int argc, char* } // while // Assume first non-option argument is the device filename.... - device = (char*) poptGetArg(poptCon); + device = strdup(poptGetArg(poptCon)); poptResetContext(poptCon); if (device != NULL) { @@ -498,6 +498,7 @@ int GPTDataCL::DoOptions(int argc, char* cerr << "Error encountered; not saving changes.\n"; retval = 4; } // if + free(device); } // if (device != NULL) poptFreeContext(poptCon); return retval;
Erm, actually that'd break in the case where the argument is missing, but the above is more a demonstration of the issue than actual proposed fix. Calling poptResetContext() in the middle of processing that context seems rather suspect in the first place.
Ok, best thing would be to report upstream I think?
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
Seems somebody already did, and it's "fixed" the same way as I suggested above: https://sourceforge.net/p/gptfdisk/code/ci/5d5e76d369a412bfb3d2cebb5fc0a7509cef878d but then it's (not so surprisingly) causing other issues: https://sourceforge.net/p/gptfdisk/mailman/message/37685936/ Submitted a PR to address this: https://src.fedoraproject.org/rpms/gdisk/pull-request/2
The PR is for rawhide but should be applied to F37 as well.
Will this change work for F36 with older popt too?
*** Bug 2121733 has been marked as a duplicate of this bug. ***
FEDORA-2022-2173cbd1cf has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2173cbd1cf
FEDORA-2022-2173cbd1cf has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2173cbd1cf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2173cbd1cf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Terje Røsten from comment #6) > Will this change work for F36 with older popt too? Yes it will. The popt API didn't change here, the gdisk usage was always wrong but got away with it due to the memory leak in popt.
FEDORA-2022-2173cbd1cf has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.