I am writing a Qt5/C++ app and the base class defines a signal, to be overridden by descendants.
The Qt IDE shows a warning on the header where I define the signal:
Signal is virtual [clazy-virtual-signal]
I don't understand the warning. I know the signal is virtual...why is that a problem
Related
I am currently learning CMSIS-RTOS v2 and I have an issue that is bugging me and I can't find the answer I need.
I am using the STM32L476-Disco board and the joystick center button as an interrupt. I have a very simple Interrupt callback for my center joystick interrupt :
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin){
//osEventFlagsSet(evt_id,0x0001);
HAL_GPIO_TogglePin(LD5_GPIO_Port,LD5_Pin);
osThreadFlagsSet(ThId_Led_Blink,0x0001);
}
When I call osThreadFlagsSet, the microcontroller freezes and nothing else happen. This is why I've put the HAL_GPIO_TogglePin : to see if the mcu was still responding or not.
I know that my interrupt resets correctly because when I only put my pin toggle, I can toggle the Led correctly.
ThId_Led_Blink is a ThreadId
osThreadId ThId_Led_Blink;
I've checked that the ID is set correctly in my debugger and it is (it's not null).
As you can see, I've tried with osEvenFlagsSet and I have the same result.
When I check the CMSIS_RTOS v2 documentation, it does specify that osThreadFlagsSet can be called from an ISR, but I am not sure if I need to do something else in that case for the Flags to be set correctly and resolve the issue when the ISR is hanging.
Thanks for your help
So after frustrating hours of searching, I finally fixed my issue.
As described in this website : https://www.freertos.org/RTOS-Cortex-M3-M4.html, for STM32 microprocessor, you need to set the NVIC Group Priority to 4. If you look on freeRTOS, they are talking about putting this line in your code :
NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );
However, the STM32 has it's own library for the NVIC and the correct function to set the priority group is :
HAL_NVIC_SetPriorityGrouping(4);
Why go with the same name when you can change everything?
So make sure to call this function before your kernel initialization if you are using nested interrupts with FreeRTOS/CMSIS RTOS.
Also, make sure that your nested interrupt priority is in the range of configured interrupt priority for your FreeRTOS, otherwise, the osThreadFlagsSet function will fail automatically.
I know that the implementation signals a MessageNotUnderstood exception, but how does that end up opening a debugger?
When an Exception remains unhandled after it has been signalled, its #defaultAction is invoked. MessageNotUnderstood>>defaultAction delegates to Error>>defaultAction, which signals an UnhandledError (another Exception). This exception, in turn, has a defaultAction whose code reads like this:
^ ToolSet debugError: self exception
...which opens the debugger if you use the StandardToolSet (which is the default in regular Squeak images).
I have a class A extending class B. Class A is autoloaded during reflection, which in turn autoloads class B.
When there is a parse in class B, I only get an exception saying class A does not exist, the parse error in class B is hidden.
A usable solution would be to somehow catch the parse error when running require_once, but the parse error should ideally be handled the normal way rather than be hidden.
I've noticed the following error popping up in the console when running my app on iOS 9 when using a storyboard. I'm using xCode7. Is this something I need to be concerned about?
-[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] ** unhandled action -> <FBSSceneSnapshotAction: 0x176bfb20> {
handler = remote;
info = <BSSettings: 0x176a5d90> {
(1) = 5;
};
}
There is nothing wrong with your code. This is a logging message internal to Apple, and you should file a radar about it.
There are two hints that show that this is probably Apple's code:
The underscore leading the method name _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion is a convention indicating that the method is private/internal to the class that it's declared in. (See this comment.)
It's reasonable to guess that the two letter prefix in FBSSceneSnapshotAction is shorthand for FrontBoard, which according to Rene Ritchie in "iOS 9 wish-list: Guest Mode" is part of the whole family of software related to launching apps:
With iOS 8, Apple refactored its system manager, SpringBoard, into several smaller, more focused components. In addition to BackBoard, which was already spun off to handle background tasks, they added Frontboard for foreground tasks. They also added PreBoard to handle the Lock screen under secure, encrypted conditions. [...]
I have no idea what the BS prefix in BSSettings is for, but
BS is shorthand for BackBoard Settings, and an analysis of this log message would indicate that it's not anything you did, and you should file a radar with steps to reproduce the logging message.
If you want to try and grab a stack trace, you can implement the category linked to here. Some would argue that overriding private API is a bad idea, but in this case a temporary injection to grab a stack trace can't be too harmful.
EDIT:
But, we still want to know what this action is. So I put a breakpoint on -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion] and started printing out register values and found a class called FBSceneImpl which had a whole bunch of information about my application:
We are able to find out which private method is called next (stored in the program counter, instruction pointer, register 15.)
I tried finding the un-handled FBSceneSnapshotAction referenced in the log, but no dice. Then, I subclassed UIApplication, and overrode _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion. Now I was able to get at the action directly, but still, we don't know what it is.
Then, I looked at the FBSceneSnapshotAction again. Turns out it has a superclass called BSAction.
Then I wrote a tool similar to RuntimeBrowser and looked up all of the subclasses of BSAction. It turns out that there's quite a list of them:
The two method names we have (one from the log and one from the program counter on the devices) indicate that these actions are used under the hood for passing actions around the system.
Some actions are probably sent up to the app delegate's callbacks, while others are handled internally.
What's happening here is that there is an action that wasn't handled correctly and the system is noting it. We weren't supposed to see it, apparently.
AFAIK, the info above is related to iOS during snapshot the screen (i suppose for double click home multitask related behaviour).I deeply investigated my application and seems that it does not get any side behaviours. You can safely ignore it, for now.
You can use the following gist simple category to test yourself against the calls to the above function:
I have figured it out, it will happen when you have IBAction method declared in .h or .m file but you have not bind it to any control.
.m example:
- (IBAction)click:(id)sender{
}
but not assigned this method to any control in storyboard.
haven't find out why it happens in my app, but at least you can catch the exception, if you want to keep this from popping up in your log pane. It's not a solution, but it might give you more insight why it is happing by inspecting any of the arguments that are passed in the catch.
swift 2 version:
import UIKit
extension UIApplication {
func _handleNonLaunchSpecificActions(arg1: AnyObject, forScene arg2: AnyObject, withTransitionContext arg3: AnyObject, completion completionHandler: () -> Void) {
//whatever you want to do in this catch
print("handleNonLaunchSpecificActions catched")
}
}
can anyone tell me what may be the reason of crash.
Application Specific Information:
* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArrayM isValid]: unrecognized selector sent to instance 0x3f4a80'
You sent the selector isValid to an array, which doesn't respond to that message. That's all that can be said without seeing the code.
Here is my case,
to solve it:
Add -all_load to the other linker flags in your build settings.
-all_load forces the linker to load all object files from every archive it sees, even those without Objective-C code.
more description:
The "selector not recognized" runtime exception occurs due to an issue between the implementation of standard UNIX static libraries, the linker and the dynamic nature of Objective-C. Objective-C does not define linker symbols for each function (or method, in Objective-C) - instead, linker symbols are only generated for each class. If you extend a pre-existing class with categories, the linker does not know to associate the object code of the core class implementation and the category implementation. This prevents objects created in the resulting application from responding to a selector that is defined in the category.
To resolve this issue, the target linking against the static library must pass the -ObjC option to the linker. This flag causes the linker to load every object file in the library that defines an Objective-C class or category. While this option will typically result in a larger executable (due to additional object code loaded into the application), it will allow the successful creation of effective Objective-C static libraries that contain categories on existing classes. Follow these steps to pass -ObjC to the linker:
In Xcode, double-click the target's name under "Targets"
in the Project window.Choose the Build pane from the ensuing Info window.
Scroll down to the Other Linker Flags build setting under the Linking collection and set its value to -ObjC.