I'm using Cuda 5.0 with two gpu cards on Ubuntu 11.10 with Nsight Eclipse.
When I try to debug a a program from in Eclipse I get
Error in final launch sequence
Failed to execute MI command:
source .cuda-gdbinit
Error message from debugger back end:
.cuda-gdbinit: No such file or directory.
.cuda-gdbinit: No such file or directory.
I looked into Eclipse debug configuration, and I have
GDB debugger: cuda-gdb
GDB command file: .cuda-gdbinit
No where on my system is the file .cuda-gdbinit.
Should I create it? If so, where and with which content?
Is there something wrong with my cuda-gdb setup?
This message is harmless. What Nsight does is explicitly instructs cuda-gdb to read .cuda-gdbinit when starting debug session to pick up any custom settings user might have. It is perfectly fine not to have that file.
To prevent Eclipse CDT / nsight from tying to load .cuda-gdbint (which you can safely do as other answers suggest), you must remove it from the "GDB command file" associated with your run/debug configuration.
To do that,
Using the menus, go to Run | Debug Configurations
Select the Run/Debug/etc configuration for which you're getting the error message
In the multi-tabbed section, select the Debugger tab
In the sub-multi-tabbed section, select Main
You should now see a GDB Command File text box. Clear it.
Related
I am working with a 64-bit Windows installer on a 64-bit Windows 10 system that has intermittent crashing issues, where it will crash and close without displaying any kind of error message. This occurs when clicking through the installer's UI, it does not actually attempt to install anything. Collecting a crash dump, I saw that it listed the exception as an "unknown error) 0xC000409. When I ran the crash dump through Visual Studio's debugger in order to obtain information, the message said:
Unhandled exception at 0x00007FFCA685C56F (ntdll.dll) in msiexec__PID__9356__Date__11_01_2021__Time_01_46_34PM__594__Second_Chance_Exception_C0000409.dmp: RangeChecks instrumentation code detected an out of range array access.
The stack trace collected from the crash dump says the following:
ntdll!LdrpICallHandler+f
ntdll!RtlpExecuteHandlerForException+f
ntdll!RtlDispatchException+244
ntdll!KiUserExceptionDispatch+2e
ntdll!LdrpDispatchUserCallTarget+e
msi!CMsiRecord::Release+12e
msihnd!CMsiHandler::CreateControls+18e
msihnd!CMsiHandler::CreateNewDialog+6ba
msihnd!CMsiHandler::RunWizard+564
msihnd!CMsiHandler::DoAction+6e6
msi!MsiUIMessageContext::ProcessMessage+1816
msi!MsiUIMessageContext::RunInstall+1ed
msi!RunEngine+1c9
msi!MsiInstallProductW+11f
msiexec!DoInstallPackage+20e
msiexec!ServerMain+1009
msiexec!WinMain+36
msiexec!__mainCRTStartup+1a0
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
As far as I am aware, there were no major changes made to the installer recently. It just suddenly started getting reported that the installer was crashing, and this was the information that I was able to compile so far. My question is if there's any way to troubleshoot the installer during runtime so that I can get to the bottom of this, or are there any potential fixes I can explore applying? I've done lots of googling on this error and I haven't been able to find a related result yet.
I have also attempted to use ProcMon to see if a file is being blocked but have yet to find anything. I attempted to attach debuggers to the installer to produce a runtime failure, but because it appears to be going into Microsoft code, I can't get a look at the source or the information that it's working with.
I attempted to gather Windows Installer logs, but the log just cuts off at the moment of crashing without displaying any useful exception information. As best as I can gather, the crash occurs when the installer tries to create a dialog.
UPDATE: Some questions:
1) Do you have any custom actions in the setup GUI?
2) Is this a GUI-set from WiX or is it your own, custom GUI?
3) These machines are not Windows 11 are they?
4) Are you installing on a very clean virtual? The below entry in the stack trace makes me wonder if the Visual C/C++ Runtime is installed on the box in the appropriate version?:
msiexec!__mainCRTStartup+1a0
This would seem to refer to "The C runtime Library (CRT)". Please check if it is installed: Microsoft Visual C++ Redistributable Latest Supported Downloads.
Logging
Verbose logging with extra debugging information (very slow) - Comprehensive answer on logging:
msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log
Quick Parameter Explanation:
/i = run install sequence
/L*vx! C:\Your.log = verbose debug logging at specified path
The x adds extra debugging information, and the ! disables the log buffer. This means there is no lost log if there are any crashes.
Silent Installation
I am wondering if the crash comes from the setup GUI alone. If this is the case you might be able to install the setup silently successfully (since this bypasses the GUI entirely). Please try this? If this fails too, perhaps it is the Visual C/C++ runtime that is missing? Or likely something else. Logging is essential as explained above.
msiexec.exe /i c:\setup.msi /QN /L*V "C:\Temp\msilog.log"
Quick Parameter Explanation:
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
/i = run install sequence
You can throw in the exclamation mark for continuous logging (no log buffer) here as well, but that will slow the installation down a lot.
Links:
Answer on silent installation here
Comprehensive answer on MSI logging
https://www.advancedinstaller.com/user-guide/read-log.html
I am trying to simulate a simple Hello world ARM example on my desktop computer. I tried both qemu and gem5. Both gives a similar error. They cannot find ld-linux-aarch64.so.1. Actually I cannot find it either. If I could find it, I will show it with -L (in qemu) or --redirects (in gem5).
The file is:
armhello: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=23a21b7a545ac510923b6b3713d2bbee092f820a, for GNU/Linux 3.7.0, not stripped
It is compiled with: aarch64-linux-gnu-gcc
I am trying to run it in qemu with:
qemu-aarch64 armhello
I got this error:
/lib/ld-linux-aarch64.so.1: No such file or directory
I try to run it in gem5 with: (simpleARM.py points to my executable (named as armhello))
build/ARM/gem5.opt configs/tutorial/simpleARM.py
I got this error:
panic: panic condition fd < 0 occurred: Failed to open file /lib/ld-linux-aarch64.so.1.
How can I solve this?
Note: I know it works when compiled --static. But I need to run more complex binaries that are dynamically linked and I cannot change those. This is just an example.
For gem5 you can use --redirects and --interp-dir: How to run a dynamically linked executable syscall emulation mode se.py in gem5?
For qemu you need -L: Using dynamic linker with qemu-arm
same problem on x86_64 machine docker build with an arm64 docker image:
FROM multiarch/qemu-user-static:x86_64-aarch64 as qemu
FROM alpine
COPY --from=qemu /usr/bin/qemu-aarch64-static /usr/bin/
# add this line to resolve
RUN apk add libc6-compat
I've started a CUDA application in the new CLion 2020.1 version. Although I can compile and run it, I am not able to debug it, not even the host code. Specifically, debug does not stop at breakpoints, even though I am running the debug build. I'm not encountering this issue with running a regular C project in CLion 2020.1. I don't receive any error message of any kind. Here is my CMakeLists.txt file:
# Setup the CUDA compiler
set(CMAKE_CUDA_COMPILER /usr/local/cuda-10.2/bin/nvcc)
# Setup the host compiler
set(CMAKE_CUDA_HOST_COMPILER /usr/bin/g++-8)
# CMAKE minimum required version
cmake_minimum_required(VERSION 3.16)
project(PageRank_GPU CUDA)
set(CMAKE_CUDA_STANDARD 14)
add_executable(PageRank_GPU main.cu graph.cu graph.cuh vertex.cuh error.cuh parser.cu parser.cuh)
set_target_properties(
PageRank_GPU
PROPERTIES
CUDA_SEPARABLE_COMPILATION ON)
Reporting that the issue has disappeared after playing around in the project settings a bit. Specifically, under Build, Execution, Deployment then Toolchain, I set the C and C++ compilers to gcc-8 and g++-8 respectively (even though I am specifying the compiler in the CMakeLists.txt file) and under CMake, I set the toolchain to "Default" (the one I just modified) instead of "Use Default". After doing that, the debugger stops at breakpoints and I am able to step through my code. I don't understand what happened because, even after reverting the changes, I cannot make the problem re-appear.
I want to export may project (game) to different desktop platforms. I exported it from eclipse (on Windows) and I get JAR file. On my machine I can start it, but on other it won't work. I guess JRE is missing there.
So, I followed LibGDX instructions how to deploy on different platforms:
https://github.com/libgdx/libgdx/wiki/Deploying-your-application
But when I run that packr.jar app I get following output:
D:\packing>java -jar packr.jar windows.json
Output directory 'D:\packing\windows' exists, deleting
Unpacking JRE
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
copying resources
minimizing JRE
unpacking rt.jar
packing rt.jar
Done!
After that I really get my exe file, all together with jre dir, my original game jar file and some config.json file, but that exe file just won't run. No failure message, just won't run. Any idea what's going on here? Or maybe there is some other tool for packing jar files?
All I need is to make my game runnable on desktop platforms: Windows, Mac & Linux.
For windows OS you could use something like launch4j which simply puts a wrapper around your jar file.
It also has the capability to provide a given jre. So your users do not need to have one installed.
Ok, solved this.
So I've found out that if I run exe file from console (cmd) and redirect output to file I can have some error report regarding the run attempt. So I did that:
myapp.exe > log.txt
and get log this log file:
Loading JVM runtime library ...
Passing VM options ...
# -Xmx1G
Creating Java VM ...
Error occurred during initialization of VM
Unable to load ZIP library: D:\packing\windows\jre\bin\zip.dll
Zip file was there, but something was wrong with it so I replaced it with one I had in my Java installation (my was larger). After that I was able to run exe file well.
I have a cuda (v4.2) program running under visual studio 2010, to which I pass various command line parameters. I want the host compiler to see the same parameters when I run through nsight (v2.2). I assume I have to do this via (right click project) -> nsight user settings->command line arguments, but haven't yet managed to find a syntax that doesn't crash nvcc. I'm assuming it's arranged around "--run-args " somehow?
** Clarification, after comment below:
Sure when you debug straight through VS, you enter your command arguments through the property pages/command arguments, and that all works fine. But through NSight, that gets ignored, so my question is, how to do it? My talk of compilers assumes that nsight runs up NVCC, which then invokes MSVC under the covers for non CUDA code. So I assume that NSight needs to pass any command line parameters down into VS, presumably via the options described above. Assuming all that is reasonable, I suspect I'm simply getting the syntax wrong inside "nsight user settings->command line arguments" and was wondering if anyone else has succeeded here. Clearer?
It is unclear if you are trying to pass command line arguments through nvcc to cl.exe or pass command line arguments to your application when it is launched through Visual Studio with the command Nsight CUDA Debugger (Nsight|Start CUDA Debugging).
To pass command line arguments to cl.exe when compiling a .cu file to cl.exe
In Solution Explorer Right click on the .cu file
Execute Properties command
In the "filename.cu" Property Pages
a. In the left pane Select "CUDA C/C++"\"Host"
b. Add parameters to pass to cl.exe in "Additional Compiler Options" or "Preprocessor Definitions"
Preprocessor definitions will go to both nvcc.exe and cl.exe.
Additional Compiler Options will be appended to -Xcompiler options.
To pass command line arguments to your application when it is launched using Nsight|Start CUDA Debugging
In Solution Explorer Right click on the project (make sure this is your startup project)
Execute Nsight User Properties command
In the "NVIDIA NSight User Settings: " dialog
a. In the left pane select "Launch"
b. In the right specify arguments in the field "Command line arguments".
These options will be passed to the application when you launch the application with (Nsight|Start CUDA Debugging).
To pass command line arguments to your application when it is launched using Debug|Start * Debugging
In Solution Explorer Right click on the project (make sure this is your startup project)
Execute the Properties command
In the " Property Pages" dialog
a. In the left pane select "Debugging"
b. In the right pane add arguments to the field "Command Arguments"
When editing project Properties and Nsight User Properties make sure to specify the Configuration and Platform at the top of the dialog.
Nsight VSE build system does not use the nvcc --run and --run-args options. If you launch using a Debug command your process will be launched by devenv.exe. If you launch using Nsight|Start CUDA Debugging or Nsight Analysis Tools your application will be launched by Nsight.Monitor.exe.
i would like to help but i am confused; you talk about passing run-time arguments to your host code under VS. then you say you want the compiler to see the same parameters. i think you dont mean compiler. build your project first in VS (using the Debug version of your build). (and I already compile my .cu into a ptx file so nvcc doesnt get invoked when i go into Nsight. ) Then this build runs when you invoke Nsight. I have not had to provide run time arguments. there is a place in the VS project under Debug to give command line arguments; maybe this is used when Nsight starts although i have my doubts. Also, there is the Nsight user -> command line arguments input you cite. I would think the latter is indeed the correct way to do it. perhaps your problem is that you need to fully build the project before you start Nsight.