We have a legacy C application that running correctly on RHEL5,RHEL6 and RHEL7.
But the same application is crashing on RHEL 8, the call stack is pointing to crash in glibc library function sscanf.
Below is the call stack top-
*#0 0x00007f437767696e in __GI__IO_vfscanf () from /lib64/libc.so.6
#1 0x00007f437768a991 in vsscanf () from /lib64/libc.so.6
#2 0x00007f4377684f48 in sscanf () from /lib64/libc.so.6*
All arguments passed to sscanf are valid, having correct values, we confirmed in gdb.
The same code is working in older RHEL versions.
Thanks in advance for your help.
all arguments have correct values
If we are to trust you on that, you shouldn't have a crash inside sscanf, but you do.
There are two things I would try if I had this problem:
Verify with valgrind that your program doesn't have heap corruption elsewhere.
Install libc debuginfo package (instructions) so you can see exactly where inside __GI__IO_vfscanf your program crashes.
Related
I'm running PyDev 6.4.1.2 on Eclipse EE Neon (4.6.3) on OS X 10.11.6 (El Capitan)
Whenever I update the PYTHONPATH and syncing is attempted, I get 3 warnings that Python has crashed. The updated PYTHONPATH still works, but I was wondering what the possible cause of this could be.
Thank you.
The reason it crashes is because when doing some_module = __import__("some.module"), dir(some_module), that module is crashing and usually means an error in compilation of such module or some wrong environment variable (so, the module is not being properly initialized).
I'm not sure PyDev prints which module was the culprit... do you have some error in your error log after the crash happens?
http://www.pydev.org/faq.html#HowdoIReportaBUG has instructions on finding the error log.
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I want to use GPU in matlab, so I installed CUDA toolkit(cuda_6.0.37), downloaded GPUmat 0.28 version. Of course my pc has geforce 850m. I clicked 'GPUstart', and it seems working and type the 'GPUmatSystemCheck', it says CUBLAS, CUFFT, CUDART installed, but there is warning 'GPUmat and SYSTEM architecture are different.'. My pc is 64 bit. Type the GPUsingle(1) on the command window, it says
'Warning: The following error was caught while executing 'GPUtype'
class destructor: Undefined function 'GPUtypeDelete' for input
arguments of type 'double'. Undefined function
'mxNumericArrayToGPUtypePtr' for input arguments of type
'GPUsingle'.'.
What should I do next? What am I missing?
I suppose you installed the newest version of GPUmat, which is a 32 bit version, and hence there is the warning. Maybe it would help to download an older version of GPUmat, which is made for 64 bit systems. I tried it myself and at least I don't get the warning anymore. Instead I have the problem that some DLL files are not found (Invalid MEX-file
'..\GPUmat\win64\bin\GPUfullInfo.mexw64': not found). You could still give it a try and see if it works for you.
Here is the situation:
Ubuntu 13.04, Matlab 2012a and Intel C++ Composer XE 2013 for Linux.
I downloaded a matlab code archive and followed the instructions in it to compile the .cpp files. Formerly when I finished installing Matlab 2012a and started it, some error messages showed up and I googled out an answer which is:
sudo ln -s /lib/x86_64-linux-gnu/libc.so.6 /lib64/libc.so.6
And then there came out another error message which told me 'missing lstdc++' when I started compiling, the idea of re-installing g++ first came into my mind, and the error message disappeared after I did so. However, finally I got an error which I could not find an answer anywhere:
>> compilemex
ld: cannot find -lguide
mex: link of ' "max_pool.mexa64"' failed.
Error using mex (line 206)
Unable to complete successfully.
Error in compilemex (line 20)
eval(exec_string{1});
During the the process of searching for a solution, I found a thread for my previous 'missing lstdc++' error which differed from what I did to fix it, does this matter or not? And another hint is that I could not find any file named like 'libguide' under the /opt/intel/ directory, how could I fix it?
Thanks in advance!
Googl'ing for libguide, i found this:
http://software.intel.com/en-us/forums/topic/284445
According to this, the build script you're using refers to an old version of the intel compiler. Newer versions seem to have the functions in libguide.so moved to libiomp5.so.
So try replacing -lguide by -liomp5.
Disclaimer: this is pure google knowledge. Personally I have no idea what either library is good for :)
Anyone tried to install papi(performance API) version 5.1.0 on the mac os 10.8 ? I am getting following errors on the make command.
zero_attach.c: In function ‘main’:
zero_attach.c:84: error: ‘PTRACE_ATTACH’ undeclared (first use in this function)
zero_attach.c:84: error: (Each undeclared identifier is reported only once
zero_attach.c:84: error: for each function it appears in.)
zero_attach.c:84: warning: passing argument 4 of ‘ptrace’ makes integer from pointer without a cast
zero_attach.c:117: error: ‘PTRACE_CONT’ undeclared (first use in this function)
The INSTALL.txt doesnt say anything on the mac os. Just says it can be installed no procedure given so i tried just the standard procedure mentioned.
On the main page of papi -> platform supported, it doesnt say about anything about mac os.
Do i need to install some drivers for this ? any help will be great..
I just installed the latest version of PAPI (5.3.0) on OS X v 10.9.1.
Following the instructions in the install file did the trick too!
wget http://icl.cs.utk.edu/projects/papi/downloads/papi-5.3.0.tar.gz
tar -xvf papi-5.3.0.tar.gz
cd papi-5.3.0/src
./configure
make
The only problem I encountered was with an undefined malloc.h, this is easily
fixed by either making a dummy malloc.h stub with
touch malloc.h
or copying a good malloc.h into the src directory
cp /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/malloc.h .
Then you should be fine with:
make
./run_tests.sh
make install
Happy performance counting!
p.s. I did this with gcc-4.7.3 (installed with homebrew).