Hi sirs,
I can confirm. Till now Shell crashes after ASSERT instead of print error.
Sergey.

On 13.10.2012, at 5:22, Andrew Fish <af...@apple.com> wrote:

> Tim,
> 
> I agree with you especially for an Application. An Application should fail 
> with an error message, and I think you could argue that a debug build should 
> just print an error message and not ASSERT.  
> 
> If you load the edk2 shell today on an old EFI system you get an ASSERT or a 
> crash. Seems like a bad design. 
> 
> Andrew Fish
> 
> 
> 
> 
> 
> On Oct 12, 2012, at 6:06 PM, Tim Lewis wrote:
> 
>> The current AutoGen.c creates a function ProcessLibraryConstructorList() 
>> which is called from the standard entry point for UEFI Shell applications. 
>> We recently ran into a case where shell applications fail because of the 
>> lack of error handling in this function. Currently, this function calls all 
>> of the functions declared with CONSTRUCTOR in their INF. For example:
>>  
>>   Status = __wchar_construct (ImageHandle, SystemTable);
>>   ASSERT_EFI_ERROR (Status);
>>  
>>   Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
>>   ASSERT_EFI_ERROR (Status);
>>  
>>   Status = __Cons_construct (ImageHandle, SystemTable);
>>   ASSERT_EFI_ERROR (Status);
>>  
>>   Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
>>   ASSERT_EFI_ERROR (Status);
>>  
>> The problem is that this function is a VOID. So, even if these constructors 
>> fail, there is no way to terminate the application.
>>  
>> We found this issue where a CONSTRUCTOR function looked for a protocol and 
>> returned an error if it failed. We always use the release version. It fails 
>> in mysterious ways because the constructor function succeeds and then 
>> launched the declared entry point, which tries to use a library function 
>> that uses the protocol, which is some garbage value and goes off in the 
>> weeds.
>>  
>> Instead, this function should return a status code and _ModuleEntryPoint 
>> (from UefiApplicationEntryPoint, etc.) should return EFI_LOAD_ERROR so that 
>> the application will fail.
>>  
>> This would prevent undefined behavior when the protocol does not exist on a 
>> platform. Otherwise the application (or the library) must still check for 
>> the protocol pointer validity, which defeats the purpose of using a 
>> CONSTRUCTOR.
>>  
>> Tim
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to