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.
Related
How can I determine where some function called in debug state? I'm in stuck with EXC_I386_GPFLT error hence I do not expect invocation such function with my test case.
You can try new Xcode 7 feature called Address Sanitizer.
In Xcode go to Product -> Scheme -> Edit Scheme, select Run, open Diagnostics tab and check Enable Address Sanitizer.
Then Product -> Clean project and run it again.
Objective-C and C code is susceptible to memory corruption issues such
as stack and heap buffer overruns and use-after-free issues. When
these memory violations occur, your app can crash unpredictably or
display odd behavior. Memory corruption issues are difficult to track
down because the crashes and odd behavior are often hard to reproduce,
and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled,
added instrumentation is built into the app to catch memory violations
immediately, enabling you to inspect the problem right at the place
where it occurs. Other diagnostic information is provided as well,
such as the relationship between the faulty address and a valid object
on the heap and allocation/deallocation information, which helps you
pinpoint and fix the problem quickly. The address sanitizer is
efficient—fast enough to be used regularly as well as with interactive
applications. It is supported in OS X, in the Simulator, and on iOS
devices.
New features in Xcode 7
I'm trying to understand how the initialization code works that ships with Keil (realview v4) for the STM32 microcontrollers. Specifically, I'm trying to understand how the stack is initialized.
In the documentation on ARM's website it mentions that one of the routines in startup_xxx.s, __user_initial_stack_heap, should not use more than 88 bytes of stack. Do you know where that limitation is coming from?
It seems that when the reset handler calls System_Init it is executing a couple functions in a C environment which I believe means it is using some form of a temporary stack (it allocates a few automatic variables). However, all of those stack'd items should be out of scope once it returns back and then calls __main which is where __user_initial_stack_heap is called from.
So why is there this requirement for __user_initial_stack_heap to not use more than 88 bytes? Does the rest of __main use a ton of stack or something?
Any explanation of the cortex-m3 stack architecture as it relates to the startup sequence would be fantastic.
You will see from the __user_initial_stackheap() documentation, that the function is for legacy support and that it is superseded by __user_setup_stackheap(); the documentation for the latter provides a clue ragarding your question:
Unlike __user_initial_stackheap(), __user_setup_stackheap() works with systems where the application starts with a value of sp (r13) that is already correct, for example, Cortex-M3
[..]
Using __user_setup_stackheap() rather than __user_initial_stackheap() improves code size because there is no requirement for a temporary stack.
On Cortex-M the sp is initialised on reset by the hardware from a value stored in the vector table, on older ARM7 and ARM9 devices this is not the case and it is necessary to set the stack-pointer in software. The start-up code needs a small stack for use before the user defined stack is applied - this may be the case for example if the user stack were in external memory and could not be used until the memory controller were initialised. The 88 byte restriction is imposed simply because this temporary stack is sized to be as small as possible since it is probably unused after start-up.
In your case in STM32 (a Cortex-M device), it is likely that there is in fact no such restriction, but you should perhaps update your start-up code to use the newer function to be certain. That said, given the required behaviour of this function and the fact that its results are returned in registers, I would suggest that 88 bytes would be rather extravagant if you were to need that much! Moreover, you only need to reimplement it if you are using scatter loading file as described.
If I compile with -O0 in ifort, the program can run correctly. But as long as I open the optimization option, like -O, -O3, -fast, there will be a SIGSEGV segmentation fault come out.
This error occurred in a subroutine named maketable(). And the belows are the phenomenons:
(1) I call fftw library in this subroutine. If I comment the sentences about fftw, it'll be ok. But I think it's not the fault of fftw, because I also use fftw in some other places of this code, and they are good.
(2) the fftw is called in a loop, and the loop can run several times when the program crashed. The segfault does not happen at the first time of entering the loop.
(3) I considered the stack overflow, but I don't think so now. I have the executable file complied by others long time ago, it's can be executed in my computer. I think that suggests it's not due to the system stack overflow.
The version of ifort is 10.0, of fftw is fftw-2.1.5. The cpu type is intel xeon 5130. Thanks a lot.
There are two common causes of segmentation faults in Fortran programs:
Attempting to access an element outside the bounds of an array.
Mismatching actual and dummy arguments in a procedure call.
Both are relatively easy to find:
Your compiler will have an option to generate code which performs array bounds checking at run time. Check your compiler documentation, rebuild your code and rerun it. If this is the cause of the problem you will get an error message identifying where your code goes awry.
Program explicit interfaces for any subroutines and functions in your program, or use modules so that the compiler generates such interfaces for you, or use a compiler option (see the documentation) to check that argument types match at compile-time.
It's not unusual that such errors (seem to) arise only when optimisation is turned up high.
EDIT
Note that I'm not suggesting that optimisation causes the error you observe, but that it causes the error to affect the execution of your program and become evident.
It's not unknown for incorrect programs to run many times apparently without fault only for, say, recompilation with a new compiler version to create an executable which crashes every time.
Your wish to switch off optimisation only for the subroutine where the segmentation fault seems to arise is, I suggest, completely wrong-headed. I expect my programs to execute correctly at any level of optimisation (save for clear evidence of a compiler bug, such things are not unknown). I think that by turning off optimisation you are sweeping a real problem with your program under the carpet, as it were.
I compile a DLL with mingw 4.5.0 and use it as a Game Maker 8.0 extension. Game Maker dynamically loads the dll. Everything appears to work (the dll functions are called and provide correct return values), but when I close Game Maker a dialog pops up: "Microsoft Visual C++ Runtime Library", "This application has requested the Runtime to terminate in an unusual way." After that, the process continues to linger in the background for a few seconds and then disappears.
This also happens when none of the functions of the dll are actually called. There is no DllMain, and all static/global variables are basic data types or std::string (it actually also happens when I remove the std::strings).
The dll statically links with zlib and libpng. The problem seems to vanish when I pass -static to the linker which (I assume) also links the runtime statically. However, this considerably inflates the size of my DLL, and it is at best a workaround until I understand what is going on.
Any ideas on what might be the cause?
Update: Actually, it seems that the problem only happens when two extensons are loaded in Game Maker: One with a dll linked with -static, and the other without. Linking both without -static makes the problem disappear. However, I still don't understand the problem, because the dlls never directly interact or share data structures.
Update 2: I recently found out that this might be related to strange behavior of Game Maker itself. It seems that global variables aren't initialized correctly when the DLL is loaded, which might cause a crash on unloading if global objects try to free memory they don't own. That would mean the -static was just a random factor that changed the value of the uninitialized memory the globals were associated with.
Update 3: Modified the above to include the info that this is about Game Maker extensions, since this is likely relevant as per Update 2.
It's just a guess. Try to look into something like the "static initialization order fiasco" that is described here. It may be that your problem is more related to the destructors (since it happens on close).
Here's an obscure Friday Morning question:
Is it possible in LabVIEW to get the callees of a VI without loading the entire VI into memory? For instance, by reading static information from the binary?
Thanks
Well there is the private/scriptig method App.Read Linker Info From File, I don't think this will load the VI into memory, for more info have a look at the LabVIEW wiki (currently off-line , here is a Google cached page) page on the linker method.
The linker method will return all the info on the VI and it's external needs (VIs, DLLs, CHMs etc).
Ton
No, I don't believe so. When you open a reference to the top-level VI, it will be loaded into memory. That's even before you have the opportunity to query it for its callees.
Ton's answer is correct. The mentioned method is an application instance method not a VI reference method. You supply the path to the VI in question to that method and it will then parse the VI structure and extract all the relevant linker information without loading the VI as such into memory (Obviously it will read in the information from the file into memory to parse it but it will not load/instantiate the VI itself).
The problem with that node is however that it is private, because it has changed its interface in the past and may do so in the future again without warning. There even was a case between 7.0 and 7.1 or so, where the interface changed without any warning in the form of a broken arrow, but when executing it with the old data structure it would simply crash. As a private node that is fully valid, as no warranties are made about the functionality of private nodes.