I tried to write some simple matrix calculation code in c++ with OpenBLAS and then import my program into R. I did not use any Rcpp related things.
When compiled alone, the c++ program works perfectly. When I commented the few lines with OpenBLAS functions, used R CMD SHLIB to compile it and used dyn.load to import the .so file into my R program, R works fine.
However, if I uncommented the OpenBLAS-involved part, R crashes every time. When run from terminal, the following error message was reported:
R(90544,0x16bd7f000) malloc: Heap corruption detected, free list is damaged at 0x6000033d0620
*** Incorrect guard value: 0
R(90544,0x16bd7f000) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort R
Also, when I run only with a single line of OpenBLAS command, there was the following error:
*** caught segfault ***
address 0x60012e797320, cause 'invalid permissions'
Do I miss something? I do need some help since I struggled with this for a long time. Thank you guys.
I found a way round. I directly use the LAPACK used by R and followed the procedure stated here medium.com/#shiansu/calling-blas-in-r-the-hard-way-da90e0206d99. With some slight adaption, my code could finally work.
Related
I am using vim for c++ programming. I have bound the compile command to ctrl+c in vim and I run it in another tmux pane by running ./main.out. My problem is that when my c++ program gives me segmentation fault error, I don't know which line has caused the problem. But when I compiled and ran the program in vscode, it showed me the line that caused the error.
I'm seeking for a way to find out the lines that cause runtime errors like segmentation fault error while running the program's binary file in console.
This is an example output when I do ./main.out:
[1] 24656 segmentation fault (core dumped) ./main.out
When compiling the program, add the -g compiler flag, or even better -ggdb3, which will give you a much prettier output, by adding debugging symbols to the executable. Also, make sure that you compile with the -O0 optimization level.
To actually debug the program, run gdb ./main.out to start the program in a debugging session. If you then run r, gdb will start executing the program, and then stop at the line that gives the segfault.
To figure out how you got to that point, run bt while in the debugging session, and you will get a backtrace, which will show you all the function calls that were made to get to the line of code that crashed.
You can of course do a lot more than this (and you will probably need to, since locating the source of an error is often only the first step). You can use p to print the values of variables, set watchpoints, and many more things. For a while now, gdb even ships with a full fledged python interpreter, so you can even write a python script for your custom debugging needs.
Learning how to use gdb can seem overwhelming at the start, but persevere, and I guarantee the effort will pay off big time :)
Ditto on Adin
Also your code can crash due to a call in which the parameter/s are acceptable but cause the proverbial out of range protection fault from some library somewhere if you don't have those debug versions. If an assembly routine is used inside there, they can do some strange things.
So don't be afraid to add temporary code to help like finding a single call that crashes when 1,000,000 other calls to the same did not.
Is why I like to use a lot of generated randoms if possible to test when you got it fixed.
I have a problem in using Rcpp from Rexcel.
(especially, sourceCpp() function)
I'm running a 64-bit Windows 10 platform.
I installed R ver 3.3.1 and RExcel.
I also installed Rtools by Rtools34.exe.
I can use RExcel properly if I don't use sourceCpp().
Hoewver, when I use sourceCpp() function, I have an error.
From Rexcel, I execute the command
library(Rcpp)
and this step, there is no error.
Next, I put the following command
sourceCpp("C:/Users/ChrisCCCCC/Desktop/ChrisCCCCC/program/samplecode.cpp")
and Run code.Then, the error message
Error in command:
sourceCpp("C:/Users/ChrisCCCCC/Desktop/ChrisCCCCC/program/samplecode.cpp")
'C:/Program' not found
attr(,class)
[1] try-error
Is anyone else know the reason of this error?
Of course I set the path for Rtools.
and I can run the code
sourceCpp("C:/Users/ChrisCCCCC/Desktop/ChrisCCCCC/program/samplecode.cpp")
with no error from normal RGui and RStudio.
Why sourceCpp() causes an error through RExcel while there is no error through normal RGui?
Can anyone help me, please?
When executing gdb> core-file , gdb gives the following errors and then crashes creating a core file:
Reading symbols from ./libtcmalloc_minimal.so.0...
*** glibc detected *** gdb: malloc(): memory corruption (fast): 0x0000000000ec04a0 ***
I haven't found any reference to gdb crashing with this error. Has anyone run into this? If so what can be done about it.
The version of GDB is: GNU gdb (GDB) SUSE (6.8.50.20090302-1.5.18)
Thanks
what can be done about it
Any crash in GDB itself is a bug.
However, nobody would care about this bug, unless it can be reproduced with current GDB (yours is 5 years old).
So, download current release of GDB (7.5.1 currently), and build it.
If it works, use it to debug your problem.
If it doesn't work, file a bug in GDB bugzilla.
If you get this error as a result of calling
ptr = (ptr_t*)malloc(sizeof(ptr_t));
in your program, it may be due a missing stdlib.h header.
Im trying to set up Klee for a project and Im running into difficulties when testing coreutils as per http://klee.llvm.org/TestingCoreutils.html
src$ $KLEE cut.bc
'main' function not found in module.
*** glibc detected *** /home/klee/Development//klee-build/Debug+Asserts/bin/klee: double free or corruption (!prev): 0x0000000003a79850 ***
The problem is most likely with the llvm build itself, not Klee, because when I dissasemble the .bc files with llvm-dis, only the module ID is there, no actual code
Looking at the build output, what strikes me as odd is this:
Potential incompatible plugin version. GCC: 4.6 (20120301). Expected: 4.6 (20120301)
Defines 'dragonegg_disable_version_check' as env variable to remove this warning
Please note that unexpected errors might occur.
Any ideas are appreaciated.
The problem is with your LLVM version. KLEE is not yet compatible with llvm3.0 or later. Try building one of llvm 2.7 .. 2.9.
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
gdb <path to the binary> <path to the core file>
For more details on gdb see GDB: The GNU Project Debugger.
Run it through AppVerifier and cdb.
E.g.
cdb -xd sov -xd av -xd ch <program> <args>