Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Do processes have a chance to terminate safely when the user calls wsl.exe --terminate or wslconfig.exe /t to terminate a distribution on WSL? I'd also like to understand if there's any difference between WSL2 and WSL1 in this respect. On linux, my understanding is that shutdown(8) sends SIGTERM to all processes, which gives them a chance to save and exit cleanly. Is this the case in WSL too through the terminate commands?
For anyone coming here, there appears to be no clear documentation on what the terminate commands do under the hood, but based on a little experimentation I don't believe they send any signals to the processes, and the behaviour is the same for WSL1 and WSL2.
Here's some sample code to trap SIGTERM (can be modified for any signal).
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
static volatile sig_atomic_t sigterm_flag = 0;
static void sigterm_handler(int _)
{
(void)_;
sigterm_flag = 1;
}
int main(void)
{
signal(SIGTERM, sigterm_handler);
while (1) {
if (sigterm_flag) {
puts("Terminated by SIGTERM");
break;
}
sleep(1);
puts("Still running...");
}
return EXIT_SUCCESS;
}
I compiled this and ran it. Then I ran wsl.exe --terminate or wslconfig.exe /t or wsl --shutdown from a separate powershell tab. No signals are trapped by the program and the WSL instance simply exits. Sending signals directly using kill works as expected and prints the trapped signal before exiting.
If anyone can shed some light on what actually happens when you call --terminate that would be useful. Also, thanks to this post for some help.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am currently learning about processor interrupts, and have run into some confusions. From what I understand, a processor has a set of external interrupts for peripherals. That way manufactures can provide a way to interrupt the processor via their own peripherals. I know that with this particular processor (ARM Cortex M0+) that once an external interrupt line is triggered, it will go to it's vector table and corresponding interrupt request offset and (I could be wrong here) will execute the ARM thumb code at that address.
And if I understand correctly, some processors will look at the value at said IRQ address, which will point to the address of the interrupt handler.
Question 1
While learning about the ARM Cortex M0+ vector table, what is the thumb code doing at that address? I am assuming it is doing something like setting the PC register to the interrupt handler address, but that is just a stab in the dark.
Question 2
Also the only way that I have found so far to handle the EIC interrupts is to use this following snippet
void EIC_Handler() {
// Code to handle interrupt
}
I am perplexed how this function is called without setup or explicit reference to it in my actual c code. How does the program go from vector table look up to calling this function?
EDIT #1:
I was wrong about the vector table containing thumb code. The vector table contains addresses to the exception handlers.
EDIT #2:
Despite getting the answer I was looking for, my question apparently wasn't specific enough or was "off-topic", so let me clarify.
While reading/learning from multiple resources on how to handle external interrupts in software, I noticed every source was saying to just add the code snippet above. I was curious how the interrupt went from hardware, all the way to calling my EIC_Handler() without me setting anything up other than defining the function and the EIC. So I researched what a vector table is and how the processor will go to certain parts of it when different interrupts happen. That still didn't answer my question, as I wasn't setting up the vector table myself, yet my EIC_Handler() function was still being called.
So somehow at compile time, the vector table had to be created and the corresponding IRQ handle pointing to my EIC_Handler(). I searched through
a good amount of SAML22 and Cortex M0+ documentation (and mis-read that the vector table contained thumb code) but couldn't find anything on how the vector table was being set up, which is why I decided to look for an answer here. And I got one!
I found that the IDE (Atmel studio) and the project configuration I had chosen came along with a little file defining weak functions, implementation of the reset handler, and the vector table. There was also a custom linker script grabbing the addresses to the functions and putting them into the vector table, which if a weak function was implemented, it would point to that implementation and call it when the appropriate interrupt request occurred.
For the Cortex M0 (and other cortexes? corticies?) the vector table doesn't contain thumb code, it is a list of addresses of functions which are the implementation of your exception handlers.
When the processor gets an exception it first pushes a stack frame (xPSR, PC, LR, R12, R3-R0) to the currently active stack pointer (MSP or PSP), it then fetches the address of the exception handler from the vector table, and then starts running code from that location.
When there is a POP instruction which loads the PC, or a BX instruction from within the exception handler the processor returns from the exception handler, it destacks the stack frame which was pushed and carries on executing from where it left off. This process is explained in the Cortex M0+ User Guide - Exception Entry And Exit
For question 2, the vector table in the Cortex M0/M0+ is usually located at address 0x00000000. Some Cortex M0/M0+ implementations allow remapping of the vector table using a vector table offset register within the system control block, others allow you to remap which memory is available at address 0x00000000.
Depending on which tool set/library you're using there are different ways of defining the vector table, and saying where it should live in memory.
There are usually weakly linked functions with the name of the exceptions available for your microcontroller, which when you implement them in your source files are linked instead of the weak functions, and their addresses get put into the vector table.
I have no experience with Atmel based ARMs, but #Lundin in the comments says the vector table is located in a "startup_samxxx.c" file. If you've started from scratch it is up to you to ensure you have a suitable vector table, and it's located in a sensible place.
Our application crashed immediately upon entering main with the following:
0x0000000000492148 in main (argc=Cannot access memory at address 0x7fffff7689fc)
After using objdump we realized there were several very large objects that were created on the stack. All this is good.
Now, we are trying to instruct g++ to inform us of such huge stack allocations at the preamble, but using -fstack-check doesn't do it in this case, possibly because the problem is in main.
I read about STACK_CHECK_BUILTIN, but is that a flag that should be provided to the compilation of g++, and not my application? The documentation is vast, but not concise.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am trying to optimize a CUDA code. I replaced expression
result = x*y+z
with
result = fmaf(x,y,z)
But, it gives an error - CUDA error: kernel launch failure (7): too many resources requested for launch
As #JackOLantern indicated, it's likely the device code compiler will make this kind of optimization for you. You can compare the two cases to see what kind of code has been emitted by using:
nvcc -ptx -arch... mycode.cu
to see what kind of PTX code got emitted in each case, or:
cuobjdump -sass myapp
to see what kind of SASS (device machine code) got emitted in each case.
You haven't supplied any actual code, but the "too many resources requested for launch" in the context of this question is most likely due to requesting too many registers per threadblock ((registers per thread) * (threads per block) should be less than the maximum registers allowable per block, i.e. per multiprocessor).
You can determine the maximum registers allowable per block for your device using the deviceQuery sample code or from the programming guide. (registers per multiprocessor)
You can find out how many registers per thread the compiler is using by specifying:
-Xptxas -v
as additional command-line switches when compiling your code.
You can use the launch bounds qualifier to instruct the compiler to use fewer registers per thread.
My Mono application crashes on Mac with this message (Full log):
$ mono --debug bin/Debug/SparkleShare.app/Contents/MonoBundle/SparkleShare.exe
[...]
Stack overflow in unmanaged: IP: 0x26eb76, fault addr: 0xbf808ffc
[...]
"in unmanaged" implies that the stack overflow is not in my code (I only have managed code) but rather in a library I embed (SQLite, DotCmis, NewtonSoft.Json) or in Mono's code.
Even though I compile and run in Debug mode, all I get is these two hexadecimals.
QUESTION: How can I investigate this stack overflow? Any trick?
Note: The same libraries (with pretty much the same code) run fine on Linux and Windows.
Handling stack overflow is quite tricky (for mono), so it might very well be that the stack overflow is actually yours. The problem lies in figuring out the stack trace.
I usually run with gdb:
gdb --args mono --debug bin/Debug/SparkleShare.app/Contents/MonoBundle/SparkleShare.exe
And then try to hit Ctrl+C after the stack has begun to grow, but before it has actually overflown (gdb gets seriously confused with stack overflows, and you'll usually have to exit gdb when that happens, which is why you'll need to catch the overflow in action).
After hitting Ctrl+C, do a thread apply all backtrace, and you'll know if a stack overflow is about to happen (one thread will have thousands of frames).
Once you have an enormous stack trace in gdb, you need to identify the cycle. This is usually quite easy just by looking at the addresses of the stack trace. Once you have this data, you can get the managed frame like this:
(gdb) p mono_pmip (0xdeaddead)
$1 = 0x0000dead "Managed frame information shows up here"
Then just do the same for all the frames in the cycle you found.
There are more tips for debugging mono with gdb here.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Original question:
What are the alternative logging modules to NSLog for an iOS application? Please explain the pros and cons that you've experienced first hand.
Additional request 1:
I did try to use the TestFlight TFLog which also helps with uploading the logs to their server but it seems to be limited when you need logging when app is running in the background. A logging system that helps with rolling/compressing the log files and server uploads would greatly help.
Additional request 2:
Another issue of NSLog that some have written about is that Apple does not like it when you submit the app for production.
Thanks.
There's always the printf family of functions, those are generally faster than NSLog, but do not have support for the %# format specifier for objects.
Lately I've been using the excellent Lumberjack framework for logging, which is asynchronous and will not have a performance impact on your code. It also has tons of customization features for log output formatting.
If you're interested in making your own NSLog variant (a complete replacement), have a look here.
If you don't want to make your own NSLog but would rather customise what the current NSLog can have a look at some of the tricks outlined on this page instead.
Personally, I prefer the redo-NSLog-from-scratch approach as it offers much more control. It does however take quite a bit more time to implement and you have to learn about variable argument lists and their implementation in order to get it working properly. This becomes particularly painful when you want to pass va_lists around to different functions. One handy feature of making your own version is that you can setup functions to log to wherever you like (the console, or different log files) - it all comes back to smart fprintf calls at the end of the day.
On the other hand if you just want to customise NSLog in-place, then really all you need to do is become familiar with a few handy compiler macros (such as __LINE__, __PRETTY_FUNCTION__, etc). This is the easier approach, and may be all that you're after, but it doesn't provide as much control as rolling your own.
Hope this helps!
you may already know that, but you can always watch variables values when debugging in XCode
check out this
Does Xcode have a watch window?
The best alternative I know is a macros, you can use it with any predefined C macro __FILE__, __PRETTY_FUNCTION__, etc.
Prototype
#define MyLog(args...) MyLogImpl(__FILE__,__PRETTY_FUNCTION__,args);
void MyLogImpl(const char *filename, const char *funcPrettyName, NSString *formatStr, ...);
Implementation
With va_start() va_end() you'll be able to get the format. In order to compensate printf lack of format support you are going to use this values as following:
NSString *messageStr = [[NSString alloc] initWithFormat:formatStr arguments:replacingArgumentParameters];
And then you are able to print the standard message together with any other data, like
fprintf(stderr, "%s %s", filename, messageStr);
which gives you not only the message itself but also the file name was calling the MYLog.
Another useful trick is to limit the messages to the current log_level or running configuration.
If you feel yourself experienced enough you could also go ahead and try to redefine the standard NSLog macros.
As "A-Live" said the best alternative is a Macro. Just define following MACRO in your .pch file.
#ifdef DEBUG
#define debug(format, ...) CFShow((__bridge void *)[NSString stringWithFormat:#"%s [LINE: %d] ==>> " format,__PRETTY_FUNCTION__, __LINE__, ## __VA_ARGS__]);
#else
#endif
Now, How to use the above Macro ?
Sample
debug(#"Version Number is 1.0");
Note:
You can disable all debug logs by Editing your schema.
Under the Edit Schema select first Tab i.e. "Info"
In "Info" tab set Build Configuration to "Release" and press "OK" button.