3/11/2023 0 Comments Terminal vs uxterm vs xtermThere is something funny about the directories being searched. Openat(AT_FDCWD, "/home/gib/bin/libqwt.so.6", O_RDONLY|O_CLOEXEC) = 3 Openat(AT_FDCWD, "/home/gib/bin/x86_64/libqwt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Openat(AT_FDCWD, "/home/gib/bin/x86_64/x86_64/libqwt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Stat("/home/gib/bin/tls", 0x7ffd269838a0) = -1 ENOENT (No such file or directory) Openat(AT_FDCWD, "/home/gib/bin/tls/libqwt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Openat(AT_FDCWD, "/home/gib/bin/tls/x86_64/libqwt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Openat(AT_FDCWD, "/home/gib/bin/tls/x86_64/x86_64/libqwt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) I'll copy the first lines and the last lines.Įxecve("/home/gib/vspheroid-fem/build-vspheroid-Qt3d-Release/vspheroid-Qt3d-first-try",, 0x7ffdf2a51980 /* 55 vars */) = 0Īccess("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)Īccess("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) Oh, there is a strict limit on the number of characters. This is horrendously long (more than 800 lines). These are my thoughts looks like a few hundred lines, and unfortunately I can't copy and paste them, unless I can find a way to make Creator use the gnome terminal program. When you run it from Creator I think it does not - doesn't Creator have an option checkbox when launching/debugging programs to say "create a (new) terminal when running this"? It might be worth switching that on to see whether that makes any differnce. One other thought: if you say outside Creator "it just sits there until I hit ctrl-C." that means the process (still) has a controlling terminal. Now, as I said I don't use Creator, but hopefully where the "command line" is for running your program you can change that to strace your-executable to try? In the "crash" case, the last few lines may give you a clue where your program is getting to just before it dies. This produces tracing output showing every system call being made. Under Linux you can run an executable via strace executable. You could also try running your program from the terminal through gdb your-executable to test the debug situation outside of Creator. You can view what Creator is passing from the environment variables it shows, and compare that against the terminal environment via env | sort, or similar. (Assuming you build for debug/non-debug similarly when you run inside or outside Creator.) The only difference between the Creator System/Build environments and the terminal environment, apart from working directory, should be environment variables. But if you do not even hit that then it implies during internal run-time start-up, and you have a deeper problem. If you put a breakpoint on the very first line of your main(), do you even get there? If you do it's somewhere in the code, and you can at least step around and see what it does in. gdb command bt) you would get a few non-assembler frames at the top, but maybe not. Not sure exactly what you mean by "I also get 24 lines of assembler code", I would have hoped that if you look at the stacktrace (e.g. IIRC, means a null, or possibly out-of-bounds, pointer dereference, somewhere.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |