-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segmentation fault produced by version check on some machines. #1177
Comments
Hey! The thing with the argument positions is probably originating from seqan3/include/seqan3/argument_parser/argument_parser.hpp Lines 550 to 556 in c78e92c
and following lines. We first check --help (we return after that) and after a while we check for --version-check (and keep going after that). --version-check should probably be checked before --help .
The cookie file should be in That's all I can say for now, but I'm sure @smehringer is happy to help 😁 |
which two machines, with which OS and which compiler are you using? Do you link pthread?
@eseiler is right. In the first case, the version check is turned off. In the second case it is not because as soon as we see help, we terminate the loop. This needs to be changed. As to the segmentation fault, the stack trace is quite short :( |
Thanks @eseiler for the path. The reason why I don't get segmentation faults is simply because I selected "never check for updates" on most machines. I.e. I get the same segmentation fault on every machine when I remove the config files. It seems that this line in my CMake file leads to the segmentation fault. If I take it out, it runs: set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static") I reproduced the error with this minimal example: #include "omp.h"
#include <seqan3/argument_parser/all.hpp>
int main(int argc, char* argv[])
{
seqan3::argument_parser myparser{"ALF", argc, argv};
myparser.info.author = "Gordon Shumway";
myparser.info.short_description = "Getting back to Melmac.";
myparser.info.version = "0.0.0";
try
{
myparser.parse();
}
catch (seqan3::parser_invalid_argument const & ext)
{
return -1;
}
return 0;
}
I run it with GCC 8.3.0 on the master branch. |
Let me guess, the machine you built on is not Debian/Ubuntu, but the machine that crashes is? You have to be really careful with static builds, it's why we went through a lot of trouble on SeqAn2 to make it work. In any case, this is not a problem of SeqAn3, it's a problem of how some linux distributions do their packaging and static builds in general. |
Adding this to your flags will likely make it work |
It crashes on Debian as well as Red Hat machines. It's not really a problem for me, I can work around it. But if it is not even working on Debian, it might be worth it to transfer the workarounds from seqan2 (I'm not sure whether this would have triggered a segmentation fault in SeqAn2)? But on the other hand my code uses OpenMP (just not my small example above). Why would it only crash in the version check and not in my parallelized code? |
Well, we are not building apps in SeqAn3 anymore. So the app developer is responsible for these kind of things. We had this only before because we were packaging all the apps with SeqAn.
Because you need pthreads and if you link against it statically not all of pthread lib is included. So many functions may work but some (like using futures/condition_variables etc) won't. In the version check we spawn a thread using future/promis idiom, so there you get the segfault. That's why the suggested fix by @h-2 will likely solve the problem as it includes the whole-archive of pthreads |
Ok, you have a point. As soon as the other bug (order of |
Hi,
I am using the argument parser. On one machine the binary runs, on the other I get a segfault.
I can fix it by turning version-check off. Interestingly the first one works, the second call produces the same segmentation fault (it seems the order of arguments matters ... shouldn't all arguments be parsed first before sending data over the internet? 🤔 ):
I include omp.h but I don't do anything fancy in my program. If I share the entire code I guess it will be hard to reproduce as it only happens on one of my machines. Do you have any idea that I could try fixing it? Where are the information stored when you first open the program and it asks you whether you want to run version checks every time? Maybe this file got messed up on that machine.
The text was updated successfully, but these errors were encountered: