First put the final collapse of local code:
InterfaceManage * InterfaceManage: : Instance ()
{
The static InterfaceManage ins.
Return & amp; Ins.
}
Program will appear in the operation of the small probability of collapse, finally through the DMP file to get the call stack information yesterday, but a mystery, this pattern of idlers in c + + 11 simple interest should be thread-safe ah, why will collapse? Exception information is as follows:
0 xc0000005: while reading position 0 x0000023f0d0d0d11 access conflict,

CodePudding user response:

You didn't lock, is thread safe?
Assume that thread 1 enters the function first, ins object initialization haven't finished, thread 2 also initialized into the function of ins, isn't this conflict?

CodePudding user response:

reference 1st floor qybao response:

you didn't lock, is thread safe?
Assume that thread 1 enters the function first, ins object initialization haven't finished, thread 2 also initialized into the function of ins, isn't this conflict?

The compiler of c + + 11 will ensure the static variable thread safety

CodePudding user response:

reference 1st floor qybao response:

you didn't lock, is thread safe?
Assume that thread 1 enters the function first, ins object initialization haven't finished, thread 2 also initialized into the function of ins, isn't this conflict?

And I to be sure, the collapse of the object structure out already, because I program in start running will be transferred to here, middle business execution in the process of using this interface will be countless times, but the program is running after a long period of time, crash here,

CodePudding user response:

refer to the second floor zcm_xh2008 response:

Quote: refer to 1st floor qybao response:

You didn't lock, is thread safe?
Assume that thread 1 enters the function first, ins object initialization haven't finished, thread 2 also initialized into the function of ins, isn't this conflict?

C + + 11 compiler will guarantee this static variables of thread safety

Does not guarantee, but as long as the startup is single-threaded initialization is no problem

CodePudding user response:

Your mistake is a null pointer, look for code where there is judgment nullptr

CodePudding user response:

reference 5 floor ggglivw reply:

your mistake is a null pointer, check out the code inside the places without judgment nullptr

0 xc0000005: access conflict, while reading position 0 x0000023f0d0d0d11 - this address is not null, why is a null pointer?

CodePudding user response:

reference 1st floor qybao response:

you didn't lock, is thread safe?
Assume that thread 1 enters the function first, ins object initialization haven't finished, thread 2 also initialized into the function of ins, isn't this conflict?

The following is a summary of the DMP file information:
Process architecture: x64
Exception code: 0 xc0000005
Exception information: the thread tried to read and write a virtual address, it is not have appropriate access to the address,

CodePudding user response:

It should not be the problem here, during the running of the static data is in a fixed memory area, can be washed clean by the memory area, access the function in the InterfaceManage will go wrong,

CodePudding user response:

refer to the eighth floor of the Pacific Ocean earth reply:

should not be the problem here, during the running of the static data is in a fixed memory area, could be washed clean by the memory area, access the function in the InterfaceManage will go wrong,

Our program compiled before release version due to set up problems when log4cpp library is the debug version of the link, but the release of the package of log4cpp library is the release version, whether can cause similar problems?

CodePudding user response:

The debug and release the best matching of DLL to lib

CodePudding user response:

The debug version and release the main difference is the debug version adds a lot of debugging code, if the debug version is no problem, there is something wrong with the release version, probably is the cause of the debug version of the distribution of memory, memory wiped out area,
Take a closer look at the source code, if there is a problem such as array overflow,

CodePudding user response:

reference 11 floor earth Pacific response:

debug version and release the main difference is the debug version adds a lot of debugging code, if the debug version is no problem, there is something wrong with the release version, probably is the cause of the debug version of the distribution of memory, memory wiped out the area,
Take a closer look at the source code, is there a problem such as array overflow,

Memory cross-border issues I checked for a long time, it is checked several times, haven't found this kind of situation,

CodePudding user response:

Memory not crossing the line of ins itself, perhaps may have other static variable memory cross-border changed ins information,
In addition, ins used by multiple threads, its members have what conflict may also, speaking, reading and writing?

CodePudding user response:

Program is running after a long period of time the question, to see if a memory leak, operation process, the output can be dynamically allocated memory size,

CodePudding user response:

When program exits collapse?

CodePudding user response:

The

reference 15 floor response: my name is hou wan floor

program exits time collapse?

not

CodePudding user response:

on the 14th floor earth reference Pacific response:

program is running after a long period of time out of the question, to see if a memory leak, operation process, the output can be dynamically allocated memory size,

Not a memory leak, troubleshoot this problem

CodePudding user response:

Estimation is memory usage related problem, check the relevant code
1. Look at the code in an array definition, probably not the length of the definition, the business data than expected, can cause memory problems,
2. The presence of unallocated memory wild pointer
.