On 09/18/13 05:21, Ryan Harkin wrote:
On 17 September 2013 01:58, David Long dave.long@linaro.org wrote:
From: "David A. Long" dave.long@linaro.org
Freeing a NULL pointer does not really have to be considered a fatal error.
Signed-off-by: David A. Long dave.long@linaro.org
MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c index 0ccb524..3333bc7 100644 --- a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c +++ b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c @@ -811,7 +811,10 @@ FreePool ( { EFI_STATUS Status;
- Status = gBS->FreePool (Buffer);
- ASSERT_EFI_ERROR (Status);
- if (Buffer == NULL) {
- DEBUG((EFI_D_WARN, "FreePool: attempt to free NULL pointer\n"));
- } else {
- Status = gBS->FreePool (Buffer);
- ASSERT_EFI_ERROR (Status);
- } }
-- 1.8.1.2
Funny enough, I found this same problem yesterday too. I started a discussion about it on the edk2 mailing list. It seems people are in favour of the status-quo as usual, despite the ASSERT being pointless.
I'm not sure if we should carry such a patch if upstream will never accept it. Adding a wrapper function that doesn't assert might be the best option.
I actually had sent this patch to an engineer at AMD a few days earlier. I should have sent it to the list then and saved you some trouble.
The patch did feel maybe a little controversial, but I didn't relish tracking down where the call was being made from. Is there any backtrace ability for debugging UEFI?
-dl