I am using gjs-1.52.5 to split GATE macro for multi-core computation with condor HPC platform. I follow the guide from openGATE instruction of gjs from here:
https://opengate.readthedocs.io/en/latest/how_to_use_gate_on_a_cluster.html
But there is always an error like following:
gjs -numberofsplits 5 -c condor -condorscript /home/goldan/GATE/ClusterP/LinesSource7-condor.script LinesSource7.mac
(gjs:27315): Gjs-ERROR **: 12:37:48.562: option parsing failed: Error parsing option -c
Trace/breakpoint trap (core dumped)
I have no idea about where is the problem with option -c, any help will be highly appreciated!
It seems you are invoking /usr/bin/gjs which is an entirely different program and not the GATE Job Splitter. Check your PATH environment variable.
Related
My application crashed due to uncaught exception (my c++ code throws uncaught exception under certain condition). I am trying to gdb the corefile. The binary library is "not striped". And the stack trace shows the function (my code) from which an uncaught exception is thrown, but when I try to print the function arguments, I always get "no symbol xxx in current context". info args also return "No symbol table info available".
Can anyone shed a light why ? is it due to the uncaught exception which unwind/corrupts the stack ?
Thanks,
Frank
Your binary lacks debug info.
If you built it with gcc, and want to debug the core you already have (if e.g. it's hard to reproduce the crash), you may be able to recover from this by rebuilding the binary with exactly the same source and command lines, adding -g to compile and link commands. (Note: you must use the same compile lines; replacing -O2 with -g wouldn't do.)
If the crash is not hard to reproduce, simply rebuild the binary with -g -O0, run it under GDB, and enjoy "easy" debugging.
The binary library is "not striped".
This doesn't mean what you think it means. Not stripped means that the symbol table is still present in the binary.
GDB will read this symbol table, and use it to map ranges of addresses to function names.
But to recover names and values of local variables and parameters, you must compile with debug info (which is what -g flag does for most compilers).
I'm using Ubuntu and gcc. My application crashes I only have Segmentation fault message in console. (previously Segmentation fault (core dumped) was reported but now it changed to just Segmentation fault).
There are no hints where the problem is so I do not understand how should I fix the problem. I need some hints to find what caused this - ideally complete stack trace or at least object type/method or something like this.
What would be the correct way of troubleshooting such type of problem? (may be compile with some extra flags, run some tools, collect core dump and analyze it somehow?)
You might well need to enable core dumps with
ulimit -c unlimited
Once you have a core dump, you can look at the program state with GDB:
gdb my_prog core
You should then have the same view that you would have had if you'd run the program under GDB until it crashed - you could just do that, rather than collecting the core dump. In particular, it will show you which line caused the segfault, and the state of the call stack at that point.
To get the best debugging view, you should tell the compiler to include debugging symbols (-g) and disable optimisation (-O0).
you can use the gdb tools to help debuging.
run gdb ./your_app_name on terminal if you have the gdb installed and you will see some infomation as follow:
.....
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./gsvod_client...done.
(gdb)
then input "r" to start your app, if it crashed again, you can type 'bt' to see the line where the problem occured.
Let me first of all apologize in case the question is unnecassary, but I am very new to modifiying compilers and cross architectural designs.
In order to evaluate the performance on various platforms I have been trying to compile the Z3 SMT solver on a raspberry pi 2. However there seems to be a problem due to the arm architecture. My intention so far was to use the configure script supplied by Mircrosoft Research, which works neatly and produces the following outcome:
Testing ar...
Testing g++...
Testing gcc...
Testing OpenMP...
Host platform: Linux
C++ Compiler: g++
C Compiler : gcc
Arithmetic: internal
OpenMP: True
Prefix: /usr
64-bit: False
Python version: 2.7
Writing build/Makefile
Copied Z3Py example 'example.py' to 'build'
Makefile was successfully generated.
python packages dir: /usr/lib/python2.7/dist-packages
compilation mode: Release
Type 'cd build; make' to build Z3
When building I first of all encouter the problem:
src/shell/install_tactic.cpp
cc1plus: error: unrecognized command line option '-mfpmath=sse'
cc1plus: error: unrecognized command line option 'u2018-msse'
cc1plus: error: unrecognized command line option 'u2018-msse2'
Makefile:3159: recipe for target 'shell/install_tactic.o' failed
make: *** [shell/install_tactic.o] Error 1
If I understood the meaning of this error correctly, these commad line options refer to clever tatics used to compute mathematical exercises and are not necessary if performance is not an issue. (Simply speaking, it should still work, even if it is slower).Removing the flags from the respective config.mk, allows building to a certain extend.
After sucessfully producing a lot of outcome files, the make process terminates with the following error:
src/util/hwf.cpp
../src/util/hwf.cpp:55:23: fatal error: emmintrin.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
Makefile:163: recipe for target 'util/hwf.o' failed
make: *** [util/hwf.o] Error 1
My question now is, whether it is again possible to compile without using emmintrin.h (simply copying the missing library to the Pi does not work, due to architectural hurdles). Has anyone ever done this?
Thank you in advance for all you helpful comments.
Both, the unsupported options and the error in hwf.cpp refer to the support for floating-point operations in Z3. The options are trying to make sure that the floating-point unit is set up correctly, and the error in hwf.cpp is because we're trying to get to hardware intrinsics for floating point operations. Essentially, the consequences of those changes are that some floating-point operations may be imprecise if those options are removed; however, not many pieces of Z3 rely on that, so it's unlikely you'll see errors later.
I do have a RPi at home, so I'll see whether we can use different options for that when I get home tonight. It may be that the RPi doesn't have a floating point unit at all though, in that case I'll have to switch it to soft floats (which we also have support for, but it may be slower).
How can I redirect execution errors of a c++ executable in bash? I've found that 2> helps while trying identify compilation errors:
g++ example.cpp 2> compErr.txt
But running the executable with that command still sends the errors to stdout:
$ ./a.out 2> e.txt
Floating point exception (core dumped)
Actually, the error "Floating point exception (core dumped)" does not come from the executable but from the shell! The messages from bash won't be suppressed by output redirection but there is a flag to enable/disable these messages.
You can install signal handlers for some of the errors which would cause the program to exit and write something to a suitable destination there. Some signals can't be intercepted and some other are hard to handle. That's the approach you can do from inside your code.
If you want to go further you could fork() your program first thing and have the actual work done in the child process. The parent process would essentially just waitpid() for the child process and use the information in the result structure received to report errors to a file.
I found something that worked in my terminal, here: http://bytes.com/topic/c/answers/822874-runtime-error-stderr-gcc-ubuntu-bash
In summary, a participant explained:
In this particular case, the reason that the string "Floating point exception" is not >redirected is that it is not produced by the process that runs ./{file} or anything that it invokes. Instead,it is being produced by the command-interpreter itself.
You can see this by telling the command interpreter to run another command interpreter, redirecting this sub-interpreter's error output. However, a bit of a >trick is required:
$ bash -c './{file}; true' >out 2>err
$ cat out
$ cat err
bash: line 1: 28106 Floating point exception./test_fail
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>