libcudart behavior on systems with no GPU application with libcudart links have unexpected SIGFPE er

[MarkP]

I’ve added a cuda-based GPGPU option to a large scientific application that is run at a number of sites not under my control. To facilitate systems with non-cuda-compliant GPUs, I include the appropriate libcudart.so with the install package as well as provide a fail-over CPU path when such a GPU is encountered. However, as was bound to happen, someone is attempting to run on a server system with no GPU (or at least no NVIDIA GPU). During startup of the application, after all .so’s are loaded but prior to the program main having been entered, the system delivers a SIGFPE (floating point exception) and kills the application – this info compliments of strace. Literally the same executable, when run on several other platforms (with NVIDIA GPUs) has no problem. When I modify the app to statically link in stub routines for all my .cu functions and thus not make reference to libcudart at link time or run time, the application runs successfully on the problem system. To the best of my knowledge all successful and the new unsuccessful runs have been made on RHEL4, RHEL5, or CentosN systems.

The above hardly proves that the libcudart.so presence in an application on a non-GPU or maybe non-NVIDIA-GPU platform causes this error, but it is somewhat suggestive. Thus, I question what behavior should one expect when attempting an app as I describe (cuda GPGPU code and a libcudart.so dependency) w.r.t.
(1) the load-time process on a non-GPU or non-NVIDIA-GPU platform?
(2) the execution of the first cuda user function (in my case generally a cudaFreeHost() or cudaGetDeviceCount()) or this same platform?

I believe I know how to get around the current problem but I still am quite curious to know whether FPExceptions or similar bad juju should be expected rather than something more graceful?

[stevejaffe]

I have exactly the same problem. There seem to be no responses to this nearly two-year-old post. I’ve found a few others, equally old, asking how to build a program that can use cuda when a suitable gpu is available or an alternate cpu-based code path when not. I haven’t found any answers.

Can someone from the excellent Nvidia development team please address this recurrent question?

Thanks!

I’ve added a cuda-based GPGPU option to a large scientific application that is run at a number of sites not under my control. To facilitate systems with non-cuda-compliant GPUs, I include the appropriate libcudart.so with the install package as well as provide a fail-over CPU path when such a GPU is encountered. However, as was bound to happen, someone is attempting to run on a server system with no GPU (or at least no NVIDIA GPU). During startup of the application, after all .so’s are loaded but prior to the program main having been entered, the system delivers a SIGFPE (floating point exception) and kills the application – this info compliments of strace. Literally the same executable, when run on several other platforms (with NVIDIA GPUs) has no problem. When I modify the app to statically link in stub routines for all my .cu functions and thus not make reference to libcudart at link time or run time, the application runs successfully on the problem system. To the best of my knowledge all successful and the new unsuccessful runs have been made on RHEL4, RHEL5, or CentosN systems.

The above hardly proves that the libcudart.so presence in an application on a non-GPU or maybe non-NVIDIA-GPU platform causes this error, but it is somewhat suggestive. Thus, I question what behavior should one expect when attempting an app as I describe (cuda GPGPU code and a libcudart.so dependency) w.r.t.

(1) the load-time process on a non-GPU or non-NVIDIA-GPU platform?

(2) the execution of the first cuda user function (in my case generally a cudaFreeHost() or cudaGetDeviceCount()) or this same platform?

I believe I know how to get around the current problem but I still am quite curious to know whether FPExceptions or similar bad juju should be expected rather than something more graceful?

[stevejaffe]

I have exactly the same problem. There seem to be no responses to this nearly two-year-old post. I’ve found a few others, equally old, asking how to build a program that can use cuda when a suitable gpu is available or an alternate cpu-based code path when not. I haven’t found any answers.

Can someone from the excellent Nvidia development team please address this recurrent question?

Thanks!

I’ve added a cuda-based GPGPU option to a large scientific application that is run at a number of sites not under my control. To facilitate systems with non-cuda-compliant GPUs, I include the appropriate libcudart.so with the install package as well as provide a fail-over CPU path when such a GPU is encountered. However, as was bound to happen, someone is attempting to run on a server system with no GPU (or at least no NVIDIA GPU). During startup of the application, after all .so’s are loaded but prior to the program main having been entered, the system delivers a SIGFPE (floating point exception) and kills the application – this info compliments of strace. Literally the same executable, when run on several other platforms (with NVIDIA GPUs) has no problem. When I modify the app to statically link in stub routines for all my .cu functions and thus not make reference to libcudart at link time or run time, the application runs successfully on the problem system. To the best of my knowledge all successful and the new unsuccessful runs have been made on RHEL4, RHEL5, or CentosN systems.

The above hardly proves that the libcudart.so presence in an application on a non-GPU or maybe non-NVIDIA-GPU platform causes this error, but it is somewhat suggestive. Thus, I question what behavior should one expect when attempting an app as I describe (cuda GPGPU code and a libcudart.so dependency) w.r.t.

(1) the load-time process on a non-GPU or non-NVIDIA-GPU platform?

(2) the execution of the first cuda user function (in my case generally a cudaFreeHost() or cudaGetDeviceCount()) or this same platform?

I believe I know how to get around the current problem but I still am quite curious to know whether FPExceptions or similar bad juju should be expected rather than something more graceful?