Describe
I'm writing a toy code with Eigen. But when I try to print the matrix I, unfortunately, meet the segment fault when cout. The following first code is my project code that meets the segmentation fault. I know that if I just write a tiny code as the second code, it works fine. So I don't know what's the matter with my project code for that it failed in the cout as the pictures show.
C++ Code
The most minimum test code is https://godbolt.org/z/GePx5b
#pragma pack(1)
#include <iostream>
#include <Eigen/Dense>
#include <string>
#include <fstream>
#define BUFFER_SIZE 256
#define WORK_SPACE "PositioningSystem/"
using Eigen::Matrix3d;
int main(int argc, char const *argv[]) {
Eigen::Matrix3d m;
m << 1, 2, 3,
4, 5, 6,
7, 8, 9;
std::cout << m << std::endl;
return 0;
}
If you write the first code #pragma pack(1), you will meet segmentation fault, and if you delete it, all work fine.
Finally find the bug
In an include file, I write such a code as the following
#pragma pack(1) //指示struct不进行内存对齐
When I delete this code, all is right. Anyone has any thoughts about this bug?
more about this
The same code with the #pragma pack(1) could run on the arm but failed on x86 platform as discussed above.
x86
OS Linux wang-X556UQK 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ubuntu 20.04 release
gcc Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
eigen 3.3.7
arm
OS Linux iTOP4412-ubuntu-desktop 3.0.15 #20 SMP PREEMPT Tue Mar 31 22:03:51 CST 2020 armv7l armv7l armv7l GNU/Linux
ubuntu 12.04 customed by vender Linaro 12.04 (GNU/Linux 3.0.15 armv7l)
gcc Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
eigen 3.0.5
Yes, I finally successfully overcome the issue. It's the wrong with the #pragma pack. So, please use the sentence following the #pragma pop, just like the new and delete must be the same to make sure the program is right.
pragma pack(push) without corresponding pop leads to stack smashing
https://gitlab.com/libeigen/eigen/-/issues/2074
Related
I am using the build tools provided by Rtools.
gcc version 8.3.0 x86_64-w64-mingw32 (Built by Jeronen for the R-project)
GNU ld version 2.33.1
eigen version 3.4.0
I have been testing various functions of the eigen package, and when I calculated the singular values using the BDCSVD object, the linker just hangs with full cpu usage. The following line is causing the trouble:
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
This line of code compiles fine. Just the particular linker does not return. I have waited a few minutes for the linker, but it just won't return.
On the other hand, when I used the latest gcc from the Windows Linux subsystem. Everything worked fine. So is this a known issue? Can it be easily fixed (but still using the build system provided by Rtools in Windows)?
PS: I have encounted this issue several times before, but the cpp files were much more complex, so I wasn't sure back then what caused the hanging linker.
Update:
A code sample is provided below. I configured my Windows copy of eigen3 using the "Unix Makefiles" option, since I do not have Visual Studio and don't want to download it.
Here is the cpp file:
#include <iostream>
#include <Eigen/Dense>
using namespace std;
using namespace Eigen;
int main()
{
double data[9];
for (int i = 0; i < 9; i++)
{
data[i] = i;
}
Map<MatrixXd> m(data, 3, 3);
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
auto v = svd.singularValues();
cout << "condition #: " << v.maxCoeff() / v.minCoeff() << endl;
}
I was trying to calculate the condition number of a singular matrix here.
Compiled using command line:
g++ -I"my eigen lib" t.cpp -o t.exe
where g++ comes from Rtools, "my eigen lib" is the eigen include directory, t.cpp the cpp file, and t.exe the build target.
Surprisingly or not, when I changed the algo from BDCSVD to JacobSVD, the compilation would succeed, even though BDCSVD defaults to JacobSVD for small matrices.
cc1plus and as both returned normally. ld keeps running forever, it seems.
Edits:
It's been awhile, but I am still looking for an answer.
If I create a simple library (built using CMake):
foo.h
#pragma once
#include <functional>
void foo(std::function<void()> handler);
foo.cpp
#include "foo.h"
void foo(std::function<void()> handler)
{
handler();
}
And then create a separate CMake project compiling an executable:
#include "foo.h"
#include <cstdlib>
#include <iostream>
int main()
{
foo([&]()
{
std::cout << "hello" << std::endl;
});
return EXIT_SUCCESS;
}
And then compile the library using MSVC (using latest platform SDK 10.0.17134.12) in Release or RelWithDebInfo (remember I'm using CMake) and I compile the executable using Clang 6 (Clang 5 is not supported with the latest Windows Platform SDK bundled with Visual Studio 17.7 https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/) also using Release or RelWithDebInfo, then I get heap corruption triggered by the std::function destructor.
To trigger heap corruption reliably, I can use gflags.
gflags -p /enable "myexe.exe" /full
It worked fine with Clang 5 on the previous platform SDK (standard Clang available for download from LLVM, not Microsoft's version). I'm assuming this is an ABI (or similar) problem or bug. It's taken a while to distill this all down and get a minimum verifiable reproduction. Does anyone have any suggestions about where to take it from here?
It does appear to be an ABI issue from what I can tell, so I reported a bug:
https://bugs.llvm.org/show_bug.cgi?id=39962
Update:
The bug was fixed in https://reviews.llvm.org/rL328386 and is included in Clang 7.0.0.
Hello i have a program in c++ which add Hello world (50000000) times in front of string and i want to see toke how long. this is my source
#include <iostream>
#include <string>
using namespace std;
int main() {
string str2("Hello");
auto start_t = chrono::high_resolution_clock::now();
for (size_t i = 0; i < 50000000; i++) str2 += "Hello";
cout << chrono::duration_cast<chrono::milliseconds>(chrono::high_resolution_clock::now() - start_t).count() << " milliseconds\n" << endl;
return 0;
}
i checked this source in 3 Different situations:
Situation 1:
os: windows
ide: clion (latest version)
MinGW: 5
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
3100 milliseconds
Situation 2:
os: windows
ide: vistual studio 2017
compile: Release
and i got this result:
700 milliseconds
Situation 3:
os: MAC OSX
ide: clion (latest version)
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
1200 milliseconds
i checked on windows and mac and i got this results... why? why the result are totally different? all the situations (Release mode and ...) are same!
Your comparisson has no stable basis.
You are comparing your code on different operating systems, with different compilers.
In order for a comparison to actually take place, you need to keep something fixed. For example, you could check with all three compilers in one system, OR in all three systems with one compiler.
Furthermore, try to use the same optimization flags on every compiler, so that they optimize the code in similar fashion.
My laptop can not compile a simple c++ code since yesterday, it works perfectly fine before.
The c++ code is can be a hello-world code in main.cpp file.
#include <iostream>
using namespace std;
int main(int argc, char** argv)
{
cout<<"Hello World"<<endl;
return 0;
}
I am trying to compile the code by
icpc main.cpp
The error information is
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/algorithm(637),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/__string(56),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/string_view(171),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/string(470),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/__locale(15),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/ios(216),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/iostream(38),
from main.cpp(1):
/Library/Developer/CommandLineTools/usr/include/c++/v1/type_traits(2065): error: expected an identifier
: public decltype((_VSTD::__is_assignable_test<_Tp, _Arg>(0))) {};
compilation aborted for main.cpp (code 2)
A few information:
I am using icpc (ICC) 17.0.4 20170411, it is installed from Intel® Parallel Studio XE Composer Edition for C++ macOS.
My mac is MacBook Pro (15-inch, 2017), version 10.12.6.
If I use gnu compiler, it works fine. While my code needs to use intel's compiler.
The code works before, do not know while it becomes this. I have already tried restarting the systems.
======================================================================
Update1: The problem happened after I update my "Command Line Tools for Xcode". It looks like the /Library/Developer/CommandLineTools/usr/include/c++/ is not right.
======================================================================
Update2: This is can be solved by using icpc -std=c++11 main.cpp
However when I change my main.cpp to
#include <iostream>
#include <vector>
#include <tuple>
using namespace std;
tuple<vector<int>, vector<int>, vector<int>>
getAllBlockMeanErrorTuple(const vector<int> &vec)
{
vector<int> fact, mean, err;
fact.resize( vec.size() );
mean.resize( vec.size() );
err.resize( vec.size() );
return make_tuple(fact, mean, err);
}
int main(int argc, char** argv)
{
cout<<"Hello World"<<endl;
return 0;
}
It has error again even if I use icpc -std=c++11 main.cpp
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tuple(401): error: type name is not allowed
-> __all<typename enable_if<_Trait<_LArgs, _RArgs>::value, bool>::type{true}...>;
detected during:
I encountered the same issue while upgrading command line tools to the version of September 2017
While not finding a proper solution, I reinstalled previous version ( April 2017) of command line tools and it solved the problem (https://developer.apple.com/download/more/#).
I am looking forward to having a clean solution.
EDIT (5/12/17):
I solved the issue by recompiling everything using gcc. At compilation, Intel compilers will use the compiler that responds to gcc and g++ in the path. An installation with homebrew and some symlink in /usr/local/bin pushes the newly installed gcc in front of clang and then avoids gcc to change at each system update. Hope it helps.
Try to check that you are using right settings
and GNU is working because it automatically set to C++
try to set compiler to c++
hope this works.
OR You can use xcode to write c++ Code.
I did a fresh installation of minGW on windows 7 64 bits, I can compile c++ without errors, however if I try to run the executable, I get
"This version of D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether ou need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
My code is
#include <iostream>
using namespace std;
int main() {
cout << "aaaa" << endl;
return 0;
}
and I'm compiling using
C:\MinGW\bin\gcc -c D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.cpp -o D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe
I believe GCC is not compiling 16 bit software, since its the last release