I run the following code in CLion:
int main()
{
char amessage [] = "oafaojfpa";
char * pmessage = "oafaojfpa";
char * apmessage = amessage;
amessage[2]='X';
*(pmessage+2)='X';
printf(amessage);
printf("\n");
printf(pmessage);
printf("\n");
printf(apmessage);
return(0);
}
The code *(pmessage+2)='X'; should raise exceptions. However, the output is:
/Users/spacegoing/Library/Caches/CLion12/cmake/generated/1ab7f406/1ab7f406/Debug/TCPL_Learn
Process finished with exit code 10
CLion only says exit code 10. But where can I view the exception message?
Only c++ code throws exceptions. In this case you are experiencing low level errors. You see a C/OS return value 10 which is BUS ERROR.
Bus errors are rare nowadays on x86 and occur when your processor cannot even attempt the memory access requested, typically:
using a processor instruction with an address that does not satisfy its alignment requirements.
modifying read only memory
Your pointer pmessage points to a string literal. This string is stored at read-only memory and trying to modify this memory leads to undefined behavior. It usually either segfaults or bus errors.
Related
In an android native application, when I call:
vkDestroyDevice( vk.device, VK_ALLOCATOR )
I've got error Error: [Validation] Code 614466292 X object 0xffffffffd3bcb900 has not been destroyed (...).
But I have called vkDestroy(Object) for each of the objects. (image, imageview, pipeline, etc)
Here is one object creation / destruction:
static void create_shader_module(const unsigned char* pBytes, const int count, VkShaderModule* pVkShaderMod) {
VkShaderModuleCreateInfo desc;
desc.sType = VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO;
desc.pNext = NULL;
desc.flags = 0;
desc.codeSize = count;
desc.pCode = (const uint32_t*)pBytes;
VK(vkCreateShaderModule(vk.device, &desc, NULL, pVkShaderMod));
}
extern unsigned char multiview_single_texture_vert_spv[];
extern int multiview_single_texture_vert_spv_size;
create_shader_module(multiview_single_texture_vert_spv, multiview_single_texture_vert_spv_size, &s_gShaderModules.single_texture_vs);
And for the destruction part:
vkDestroyShaderModule(vk.device, s_gShaderModules.single_texture_vs, NULL);
When I call vkDestroyShaderModule, vk.device is still active, and I 've got no error.
But as soon as I call vkDestroyDevice(), I've got error:
OBJ ERROR : For device 0xeb0ac330, ShaderModule object
0xffffffffeb0c6240 has not been destroyed. The spec valid usage text
states 'All child objects created on device must have been destroyed
prior to destroying device'
Freeing the struct memory with memset(&s_gShaderModules, 0, sizeof(s_gShaderModules)); does not solve the problem.
The error is on an android device, unfortunaly I can't test the application on another device.
Everything else in the application works, I even destruct and recreate some of the objects at runtime without error, except the application crash on exit.
I've just removed the validation layers, and surprisingly the application no longer crashes, the closing sequence ends successfully. Why didn't I try it earlier?
The problem only occurs with layers, it may be due to their order in the extension array.
Assuming I'm in a C++ program, I want to convert these reports to exceptions. Is using a C++ throw statement a reasonable way to do it, or am I stuck just redirecting to stderr?
No, you can not throw C++ exceptions from your hook.
It may work some of the time - but in general - when the hook is invoked the CRT is in an indeterminate state and may no longer be able to throw or handle exceptions. Throwing an exception when the CRT is in trouble, is a similar scenario to throwing an exception from the destructor of an object, that has been called during stack unwinding, due to an exception. Also, the depths of the CRT is not an appropriate place to throw C++ exceptions, doing so might leave the runtime in a bad state - if it wasn't already!
What you should do is the following:
int no_dialog_box_but_act_as_if_it_had_appeared_and_abort_was_clicked (int /* nRptType */,
char *szMsg,
int * /* retVal */)
{
fprintf (stderr, "CRT: %s\n", szMsg);
/* raise abort signal */
raise (SIGABRT);
/* We usually won't get here, but it's possible that
SIGABRT was ignored. So exit the program anyway. */
_exit (3);
}
I have built kernel 2.6.35 on my system with some specific requirement. I also built some app defined module with the same kernel. I booted up the built version and I find it did not work properly as there is some gui and other modules missing problem. But the system booted up and I did a insmod app.ko. I faced a crash. I found out that it is a stack problem. A caller function in the APP is passing address of two local variable. like int a, b; add (&a, &b); I checked the values of &a and &b before passing and it remained non-null but when i receive the same in the calling function, both the &a, &b are NULL or some garbage value. I increased the stack size but nothing happened. When i skipped the function call, I could see that many allocation of memory has also failed. So I think it should be memory problem. Is there anything I should be checking for gcc option to define the stack or check for stack overflow. Any hints on this could help me a lot. Thanks in advance. I just made some abstract examples since the original code section takes lot of time to explain.
main()
{
struct DMAINFO* pDmaInfo;
struct DESC* pDesc;
/* printk("The function aruguments are Desc = %p and DmaInfo %p", &pDesc, &pDmaInfo); */
Create_DMA(&pDesc, &pDmaInfo);
}
void Create_DMA(**ppDesc, **ppDmaInfor)
{
printk("The function aruguments are Desc = %p and DmaInfo %p", ppDesc, ppDmaInfo);
}
The printk statement inside create_DMA gives me NULL values, but the same print statement in the main function before the create_DMA call has some values.
pDesc and pDmaInfo is un-initialed before Create_DMA(), so it contains garbage value and causes the print statement in the main function before the create_DMA call outputs some values.
When Create_DMA() is called, Create_DMA() try to allocation memory and some other resources and put the result at pDesc and pDmaInfo. When Create_DMA() fails, the value of pDesc and pDmaInfo is undefined, depends on process of Create_DMA().
To avoid such problem, you should always init the pDesc and pDmaInfo and write the Create_DMA() carefully.
main()
{
....
struct DMAINFO* pDmaInfo = NULL;
struct DESC* pDesc = NULL;
....
}
I am using Mac OS 10.6.5, g++ 4.2.1. And meet problem with following code:
#include <iostream>
#include <sys/signal.h>
using namespace std;
void segfault_handler(int signum)
{
cout << "segfault caught!!!\n";
}
int main()
{
signal(SIGSEGV, segfault_handler);
int* p = 0;
*p = 100;
return 1;
}
It seems the segfault_handler is called infinitely and keep on print:
segfault caught!!!
segfault caught!!!
segfault caught!!!
...
I am new to Mac development, do you have any idea on what happened?
This is because after your signal handler executes, the EIP is back to the instruction which causes the SIGSEGV - so it executes again, and SIGSEGV is raised again.
Usually ignoring SIGSEGV like you do is meaningless anyway - suppose the instruction actually read some value from a pointer to a register, what would you do? You don't have any 'correct' value to put in the register, so the following code will likely SIGSEGV again or, worse, trigger some logic error.
You should either exit the process when SIGSEGV happens, or return to a known safe point - longjmp should work, if you know that this is indeed the safe point (the only possible example that comes to mind is VM interpreters/JITs).
Have you tried returning 0 instead of 1 in your program? Traditionally, values other than 0 indicate error. Also, does removing the two lines dealing with *p resolve it?
Visual C++ debug runtime library features so-called allocation hooks. Works this way: you define a callback and call _CrtSetAllocHook() to set that callback. Now every time a memory allocation/deallocation/reallocation is done CRT calls that callback and passes a handful of parameters.
I successfully used an allocation hook to find a reproduceable memory leak - basically CRT reported that there was an unfreed block with allocation number N (N was the same on every program run) at program termination and so I wrote the following in my hook:
int MyAllocHook( int allocType, void* userData, size_t size, int blockType,
long requestNumber, const unsigned char* filename, int lineNumber)
{
if( requestNumber == TheNumberReported ) {
Sleep( 0 );// a line to put breakpoint on
}
return TRUE;
}
since the leak was reported with the very same allocation number every time I could just put a breakpoint inside the if-statement and wait until it was hit and then inspect the call stack.
What other useful things can I do using allocation hooks?
You could also use it to find unreproducible memory leaks:
Make a data structure where you map the allocated pointer to additional information
In the allocation hook you could query the current call stack (StackWalk function) and store the call stack in the data structure
In the de-allocation hook, remove the call stack information for that allocation
At the end of your application, loop over the data structure and report all call stacks. These are the places where memory was allocated but not freed.
The value "requestNumber" is not passed on to the function when deallocating (MS VS 2008). Without this number you cannot keep track of your allocation. However, you can peek into the heap header and extract that value from there:
Note: This is compiler dependent and may change without notice/ warning by the compiler.
// This struct is a copy of the heap header used by MS VS 2008.
// This information is prepending each allocated memory object in debug mode.
struct MsVS_CrtMemBlockHeader {
MsVS_CrtMemBlockHeader * _next;
MsVS_CrtMemBlockHeader * _prev;
char * _szFilename;
int _nLine;
int _nDataSize;
int _nBlockUse;
long _lRequest;
char _gap[4];
};
int MyAllocHook(..) { // same as in question
if(nAllocType == _HOOK_FREE) {
// requestNumber isn't passed on to the Hook on free.
// However in the heap header this value is stored.
size_t headerSize = sizeof(MsVS_CrtMemBlockHeader);
MsVS_CrtMemBlockHeader* pHead;
size_t ptr = (size_t) pvData - headerSize;
pHead = (MsVS_CrtMemBlockHeader*) (ptr);
long requestNumber = pHead->_lRequest;
// Do what you like to keep track of this allocation.
}
}
You could keep record of every allocation request then remove it once the deallocation is invoked, for instance: This could help you tracking memory leak problems that are way much worse than this to track down.
Just the first idea that comes to my mind...