I am new to ARMv8 architecture and while reading the v8 exception vectors I am not able to understand significance of adding SP_EL0 level vectors while SP_ELx vector set exists. What I am trying to find a use case where this is useful. I understand that when the exception is taken at same level by default the stack of same exception level is used for example if EL2 (Hyp) mode is defined then if exception occurs while being at EL2 level the stack defined at EL2 will be used but not sure if I configure to use EL0 level stack under what use cases this could be useful ? Can some one give a use case and explain ?
Also while going through the spec it seems these two different stack usage idea is taken from Cortex-M architecture but i am not very clear with thread and handler modes as well. Can any one explain it ?
Just wanted to add here that ARMv7 doesn't have thread and handler concept so i am not clear requirement in ARMv8.
Thanks
SP_EL0 is the "normal" stack pointer. Your code that runs in any EL should be running on SP_EL0 whenever it can. SP_EL1/2/3 is the "exception" stack pointer for that mode. When an exception, fault, or interrupt happens, the processor switches to this stack (and possibly switches EL). Your exception handler code should do what it needs to save the exception state and get itself onto SP_EL0 to complete handling the exception.
That is, your EL0 user code, your EL1 kernel code, your EL2 hypervisor, and your EL3 monitor should all be using SP_EL0 except in the early stages of their exception handlers. If you were to take a nested exception while on SP_ELx (non-zero), you could blow over your stack, ELR, FAR, etc. which is why you want to save these and get back to SP_EL0 as soon as you can.
I have some delphi code, kind of like this:
try
//some code
//occasionally throws an exception here, for example an EIndexOutOfRangeException
//more code...should get skipped if exception is thrown
finally
// there may or may not be any important cleanup code here
end;
The exception in this case is not something that needs handling beyond breaking out of the try block. So, before mad-except was added to the project for error troubleshooting, this code was "working". But now I'm getting bug reports because MadExcept is reporting the uncaught exception.
Related question, MadExcept triggers on try finally indicates the behavior of MadExcept breaking in such circumstance is "expected" because the exception isn't "handled".
I would like some clarification about what my options are as far ways to prevent a mad-except dialog from popping up when this code runs, regardless of whether there's an internal exception being thrown and ignored.
So I'm correct in thinking there's no switch to disable MadExcept from breaking on unhanded exceptions in a try/finally block? And I'm going to need to explictly "catch" the exception even if I wish to ignore it?
Should I be doing something like this (ignore any exception):
try
//some code
//sometimes throws EIndexOutOfRangeException here
//more code...should get skipped if exception is thrown
except do begin end;
end;
or perhaps (ignore a very specific exception):
try
//some code
//sometimes throws EIndexOutOfRangeException here
//more code...should get skipped if exception is thrown
except on E : EIndexOutOfRangeException do begin end;
end;
or maybe it needs to be:
try
try
//some code
//sometimes throws EIndexOutOfRangeException here
//more code...should get skipped if exception is thrown
except on E : EIndexOutOfRangeException do begin end;
finally
// some cleanup code
end;
If all three of those are valid solutions, should I prefer one over the other for any reason?
So I'm correct in thinking there's no switch to disable MadExcept from breaking on unhanded exceptions in a try/finally block?
Yes. try/finally is not exception handling; it's guaranteed cleanup, whether or not an exception occurs. As such, try/finally blocks are completely irrelevant to exception handling tools such as MadExcept.
And I'm going to need to explicitly "catch" the exception even if I wish to ignore it?
Yes. That's how exceptions work. They work their way down the stack until they find a handler that catches them. If no such handler exists, the OS interprets it as a crash and terminates the program. Delphi's TApplication object installs a handler very close to the bottom of the call stack so that your program won't crash, and MadExcept hooks this so that if an exception reaches this point, a report will be generated.
If you want to ignore an exception, yes, you do need to catch it, because what you are doing is formally "handling the exception by catching it at this point in the stack unwinding and ignoring it." That part about "catching it at this point in the stack unwinding" is important, since it means that the stack unwinding halts at that point and the program resumes normal execution. If you just ignored it, (ie. did nothing about it in your code, including not installing an exception handler,) it would continue to unwind the stack all the way to the default handler, whether or not you had MadExcept installed.
So yeah, in this case, example #2 is the correct course of action. Example #3 would be valid too, if you have cleanup code that needs to be performed at this point. But example #1 should never be done under any circumstances because it means you might end up ignoring an exception that you were not anticipating, and then you end up with corruption in your program and you never become aware of it.
It seems to me that you have a fundamental mis-understanding about what finally means.
A finally block does not influence the propagation of an exception. It just ensures that the finally block will execute, even if an exception has been raised, or the normal execution flow has been modified by exit, break etc.
Take the try/finally out and madExcept will still report that the program raised an exception that was not handled.
There are ways to tell madExcept to ignore certain exceptions. For instance some exceptions should be silent. The canonical example of such is EAbort. You would use RegisterExceptionHandler to customise how unhandled exceptions are treated. Although, as I will explain, I doubt this to be the solution for your problem.
What you need to do next is forget about madExcept. You need to work out what to do about this exception. Do you want to handle it here, or do you need to let the exception propagate? Only you can really know that. But madExcept is not the driver here. What must drive your decision is the correct execution of your program. Should the exception be handled or not, to make your program behave correctly? You must get that right first, and then worry about madExcept.
If you need to handle it here, then handle it selectively. Don't catch all exceptions. That's an absolute no-no. But if you handle it here, ask yourself if that is sensible. The code failed to perform some action. Is there some subsequent code that relies on that action succeeding? By handling the error, and ignoring it as you propose, you are forcing all subsequent code to be ambivalent about the success or failure of this action. That seems highly dubious to me.
Now, the exception is EIndexOutOfRangeException. That means you wrote something like A[i] where the value of i is invalid. I cannot think of a scenario where that would be acceptable. So it looks to me that your program contains an error and is simply using an invalid index. You should fix that error properly by not accessing out of bounds. Don't suppress the exception, stop it being raised.
Another way to look at this. How can you tell the difference between your current situation, and that which would arise from writing A[-i] instead of A[i]? Suppressing the exception means that you cannot detect such egregious errors as this.
The bottom line, so far as I can tell, is that madExcept is reporting an error in your code. You should regard madExcept as your friend and listen to what it says. It is telling you that you have a defect in your code that should be fixed.
I am working on Struts2 and spring integrated project.
I am getting OGNL exception as: -
Error setting expression 'lookupLicProductSKU.udiPID' with value '[Ljava.lang.String;#1feae0f'
ognl.OgnlException: target is null for setProperty(null, "udiPID", [Ljava.lang.String;#1feae0f)
I also have Spring AOP configured for all the actions to capture few logs. When ever AOP in in action and when I get the OGNL exception specified above, the flow breaks. If I remove the AOP defined in applicationContext.xml, flow runs smooth though there are the above specified OGNL exceptions. I do not understand the reason why this is happening.
Is there a way to make it work with AOP in place? Please let me know.
my question is related to this question
We have different aspect class that do #around advice on different part of an application (fat client in Swing) to measure the execution time.
I have another aspect (ExceptionHandler) that do #around on all the aspects method i wrote.
I did this to avoid that the aspects created would throw exception and make the client application fails. So basically, i try catch the Proceed of my other #around method and just log exception that arise. I only throw an exception when i detect it come from the proceedingJoinPoint
if (joinPoint.getSignature().getDeclaringTypeName().equalsIgnoreCase("org.aspectj.lang.ProceedingJoinPoint")) {
throw exception;
}
Is it valid to do this?
In Eclipse with AJDT the app run fine and i tested the ExceptionHandler and it worked as expected.
But in other env. (Integration) the application fail as soon as it meet a line advised by the exceptionHandler with this Error
Exception in thread "main" java.lang.NoSuchMethodError: com.xxx.yyy.aop.aspect.ExceptionHandlerAspect.aspect
Of()Lcom/xxx/yyy/aop/aspect/ExceptionHandlerAspect;
at com.xxx.yyy.aop.aspect.ecs.AspectBaseEcs.inspectLoginInfo(AspectBaseEcs.java:65)
at com.xxx.yyy.app.es.security.Security.loadApplications(Security.java:172)
at com.xxx.yyy.app.es.gui.VSDlgLogin.loadSecurity(VSDlgLogin.java:346)
at com.xxx.yyy.app.es.ApplicationSuite.start(ApplicationSuite.java:839)
at com.xxx.yyy.app.es.ApplicationSuite.main(ApplicationSuite.java:501)
I have also decompile the code to see if aspectOf() was weaved into my ExceptionHandler and the method is there!!!!!!!???????????
Why this error rise...?
I'm clueless.
Finally found the problem. Our Application had a dependency on common module jar that was containing aspect too.
The base package name was the same : com.xxx.aop and the base class we used for our aspects was the same name!!!! So 2 com.xxx.aop.AspectBase.class were loaded.
Since we used a flag in our ant build file to enable compile time weaving at yes/no, one of our AspectBase.class was not weaved while the other was.
Can't believe i didn't see that before!!!!!
When exception generated I want to show some additional information (source code) for particular exception. But grails have very hairy exceptions (it's all about groovy dynamic nature). It's my problem where to get and how to display source code. All I need is file/line information.
So... Is there any possibility to get file and line where exception were generated in grails/groovy?
Hmm, you aren't already getting this? All my grails exceptions have file/line information in them by default. The only difficulty is that if the exception is in a closure, it doesn't show the actual closure name. Could you post a sample stacktrace?