Is the memcpy() function reentrant?

I call some C++ functions inside a signal hand开发者_开发知识库ler and my program is terminated by segmentation fault. When I check with gdb, memcpy() function is where i get SIGSEGV. I would like to know if memcpy() is a reentrant function or not?

In all but the most highly embedded platforms, it'll be reentrant. You mention SIGSEGV so I assume it's not one of those. In this case it's most likely memcpy() isn't the culprit: it's the caller's fault. If you ask memcpy() to copy bad pointers (or bad length) then it'll be the one which faults. You could easily do this:

memcpy(NULL, NULL, 123456789);

That'll cause a SIGSEGV and it'll tell you memcpy() caused it. Of course, it's not memcpy's fault - it's just doing what you told it. Your signal handler is calling it with something odd. A backtrace (in gdb or whatever tool you have) to the site of the caller should show what you called it with. Failing that, just printf the arguments you're passing to memcpy.

Some relevant information concerning (non)reentrant functions and signal handlers (as far as relevant to the GNU C library) can be found at http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html#Nonreentrancy:

This part seems especially relevant to your question:

• "Merely reading from a memory object is safe provided that you can deal with any of the values that might appear in the object at a time when the signal can be delivered. Keep in mind that assignment to some data types requires more than one instruction, which means that the handler could run “in the middle of” an assignment to the variable if its type is not atomic."

• "Merely writing into a memory object is safe as long as a sudden change in the value, at any time when the handler might run, will not disturb anything."

I don't see why it could not be reentrant. I'm not sure, but i think its a lot based on the libraries you use.

Unless memcpy is BADLY implemented, it is reentrant. It will only work with what you give it - the pointers and the length value. All parameters are passed by value, so once the function has been activated, these values will not change on its stack frame, regardless of signals and/or other threads.

I think that the problem is that you are using as parameters for the memcpy function a invalid (or deleted) pointer, please check your code carefully.

Regards.