Run environment in Qt Creator
-
wrote on 14 Sept 2019, 05:21 last edited by gibbogle
I've stripped-down my code for the purpose of understanding why invoking it in Qt Creator gives a different behaviour than terminal execution. The program does essentially nothing. The mainwindow is created, but show() is not called. After app.exec() it just sits there until I hit ctrl-C. This is the expected behaviour, and this is what happens in a terminal when it's run from the command line. But when I click the green arrow in Qt Creator, with the same Working Directory as the terminal invocation, the program crashes.
This happens whether I select System Environment or Build Environment. I'd like know why it crashes. How can I find this out? -
I've stripped-down my code for the purpose of understanding why invoking it in Qt Creator gives a different behaviour than terminal execution. The program does essentially nothing. The mainwindow is created, but show() is not called. After app.exec() it just sits there until I hit ctrl-C. This is the expected behaviour, and this is what happens in a terminal when it's run from the command line. But when I click the green arrow in Qt Creator, with the same Working Directory as the terminal invocation, the program crashes.
This happens whether I select System Environment or Build Environment. I'd like know why it crashes. How can I find this out?wrote on 14 Sept 2019, 08:05 last edited by JonB@gibbogle
If it "crashes". start it off with debugging from Qt Creator (I don't use it, for "green arrow" there will be one which is just "Run" and another which is "Debug Run" or similar) and you will get a stack trace of where it crashes. If not, something else is happening. -
@gibbogle
If it "crashes". start it off with debugging from Qt Creator (I don't use it, for "green arrow" there will be one which is just "Run" and another which is "Debug Run" or similar) and you will get a stack trace of where it crashes. If not, something else is happening.wrote on 14 Sept 2019, 22:56 last edited by gibbogle@jonb My question mainly concerns the run environments. What makes the one used in Qt Creator different from the system environment used in a terminal?
Running in debugging mode gives a popup "The inferior stopped because it received a signal from the operating system: SIGSEGV. I also get 24 lines of assembler code, which convey nothing to me. -
@jonb My question mainly concerns the run environments. What makes the one used in Qt Creator different from the system environment used in a terminal?
Running in debugging mode gives a popup "The inferior stopped because it received a signal from the operating system: SIGSEGV. I also get 24 lines of assembler code, which convey nothing to me.wrote on 15 Sept 2019, 07:20 last edited by JonB@gibbogle
SISSEGV, IIRC, means a null, or possibly out-of-bounds, pointer dereference, somewhere. 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.gdbcommandbt) you would get a few non-assembler frames at the top, but maybe not.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. But if you do not even hit that then it implies during internal run-time start-up, and you have a deeper problem..(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. 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. You could also try running your program from the terminal throughgdb your-executableto test the debug situation outside of Creator.If you're still stuck. Under Linux you can run an executable via
strace executable [args]. This produces tracing output showing every system call being made. In the "crash" case, the last few lines may give you a clue where your program is getting to just before it dies. Now, as I said I don't use Creator, but hopefully where the "command line" is for running your program you can change that tostrace your-executableto try?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. 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.
These are my thoughts :)
-
Hi,
To add to @JonB, Qt Creator modifies the PATH, (DY)LD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH environnement variables, depending on the OS, in order for your application to find the Qt version of the Kit you are using to build it.
-
@gibbogle
SISSEGV, IIRC, means a null, or possibly out-of-bounds, pointer dereference, somewhere. 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.gdbcommandbt) you would get a few non-assembler frames at the top, but maybe not.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. But if you do not even hit that then it implies during internal run-time start-up, and you have a deeper problem..(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. 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. You could also try running your program from the terminal throughgdb your-executableto test the debug situation outside of Creator.If you're still stuck. Under Linux you can run an executable via
strace executable [args]. This produces tracing output showing every system call being made. In the "crash" case, the last few lines may give you a clue where your program is getting to just before it dies. Now, as I said I don't use Creator, but hopefully where the "command line" is for running your program you can change that tostrace your-executableto try?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. 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.
These are my thoughts :)
-
@gibbogle
SISSEGV, IIRC, means a null, or possibly out-of-bounds, pointer dereference, somewhere. 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.gdbcommandbt) you would get a few non-assembler frames at the top, but maybe not.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. But if you do not even hit that then it implies during internal run-time start-up, and you have a deeper problem..(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. 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. You could also try running your program from the terminal throughgdb your-executableto test the debug situation outside of Creator.If you're still stuck. Under Linux you can run an executable via
strace executable [args]. This produces tracing output showing every system call being made. In the "crash" case, the last few lines may give you a clue where your program is getting to just before it dies. Now, as I said I don't use Creator, but hopefully where the "command line" is for running your program you can change that tostrace your-executableto try?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. 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.
These are my thoughts :)
wrote on 15 Sept 2019, 22:11 last edited by gibbogle@jonb There doesn't seem to be a way to change the command line in Qt Creator, you can only supply arguments.
With a breakpoint at the first line in main(), the execution doesn't reach there. The Disassembler screen shows 24 lines of assembler, but the green arrow (presumably indicating the failure point) is on the 6th line (the last here):
0x7fffee371fda 00 00 add %al,(%rax)
0x7fffee371fdc 00 00 add %al,(%rax)
0x7fffee371fde 66 90 xchg %ax,%ax
0x7fffee371fe0 48 8b 05 21 0f b2 00 mov 0xb20f21(%rip),%rax # 0x7fffeee92f08
0x7fffee371fe7 48 89 05 ba 6b b3 00 mov %rax,0xb36bba(%rip) # 0x7fffeeea8ba8
0x7fffee371fee f0 ff 00 lock incl (%rax)I have tried ticking the "Run in terminal" box, but that had no effect.
A couple of the linked libraries are Release, not Debug, but I don't know if that could cause this crash - anyway, it doesn't when I run the program outside Qt Creator. -
Hi,
To add to @JonB, Qt Creator modifies the PATH, (DY)LD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH environnement variables, depending on the OS, in order for your application to find the Qt version of the Kit you are using to build it.
-
@sgaist I gathered that something of the sort was being done. I'm not sure how to see exactly what PATH and LD_LIBRARY_PATH are being used, but I also can't see why some inconsistency there would cause this segment violation error.
A couple of the linked libraries are Release, not Debug, but I don't know if that could cause this crash
On Linux: no, on Windows: indeed.
But for all platforms, you cannot mix Qt libraries of different versions.
So if, for example, your
LD_LIBRARY_PATHcontains one Qt version, and you want to run against another version in Creator (which adds the other Qt version toLD_LIBRARY_PATHtoo), you might encounter strange things.Newer Creator versions let you open a terminal with run environment set up, you can use that for further investigation.
Regards
-
A couple of the linked libraries are Release, not Debug, but I don't know if that could cause this crash
On Linux: no, on Windows: indeed.
But for all platforms, you cannot mix Qt libraries of different versions.
So if, for example, your
LD_LIBRARY_PATHcontains one Qt version, and you want to run against another version in Creator (which adds the other Qt version toLD_LIBRARY_PATHtoo), you might encounter strange things.Newer Creator versions let you open a terminal with run environment set up, you can use that for further investigation.
Regards
wrote on 16 Sept 2019, 06:30 last edited by@aha_1980 I'm running a pretty recent version of Creator, 4.9.1, but I can't see how to open a terminal with run environment set up. I do see the checkbox for 'Run in terminal', and there is a field 'Run configuration', which currently holds the name of the executable. Is that related to what you have mentioned? Can you give me some pointers?
I don't have another Qt version in LD_LIBRARY_PATH.
Thanks
-
@aha_1980 I'm running a pretty recent version of Creator, 4.9.1, but I can't see how to open a terminal with run environment set up. I do see the checkbox for 'Run in terminal', and there is a field 'Run configuration', which currently holds the name of the executable. Is that related to what you have mentioned? Can you give me some pointers?
I don't have another Qt version in LD_LIBRARY_PATH.
Thanks
In Creator 4.10 it's here:
It may look a bit different in 4.9, but the Projects context menu on a file contains that entry.
Regards
-
In Creator 4.10 it's here:
It may look a bit different in 4.9, but the Projects context menu on a file contains that entry.
Regards
wrote on 16 Sept 2019, 10:16 last edited by@aha_1980
When I open a terminal with any one of the three environment options (Build, System, Run) and execute the program at the command line, it doesn't crash. It seems that for the purposes of running my program the three environments are all equivalent. When it is invoked by one of the green arrows in Creator, it crashes. -
@aha_1980
When I open a terminal with any one of the three environment options (Build, System, Run) and execute the program at the command line, it doesn't crash. It seems that for the purposes of running my program the three environments are all equivalent. When it is invoked by one of the green arrows in Creator, it crashes.@gibbogle said in Run environment in Qt Creator:
@aha_1980
When I open a terminal with any one of the three environment options (Build, System, Run) and execute the program at the command line, it doesn't crash. It seems that for the purposes of running my program the three environments are all equivalent. When it is invoked by one of the green arrows in Creator, it crashes.Ok, so we still have no solution for your problem, but we know that the environment is unguilty.
Does that also happen if you create a "Hello World" example with the wizards?
And coming back to @JonB's
strace: you can create a custom run configuration (Project > Build & Run > Run > Run configuration > Add > Custom) and see which output you get, hopefully that gives some insight?Regards
-
@gibbogle said in Run environment in Qt Creator:
@aha_1980
When I open a terminal with any one of the three environment options (Build, System, Run) and execute the program at the command line, it doesn't crash. It seems that for the purposes of running my program the three environments are all equivalent. When it is invoked by one of the green arrows in Creator, it crashes.Ok, so we still have no solution for your problem, but we know that the environment is unguilty.
Does that also happen if you create a "Hello World" example with the wizards?
And coming back to @JonB's
strace: you can create a custom run configuration (Project > Build & Run > Run > Run configuration > Add > Custom) and see which output you get, hopefully that gives some insight?Regards
wrote on 16 Sept 2019, 23:16 last edited by@aha_1980
I am able to build and run the examples, and also an application to test Qt3d functionality that I made from a couple of the examples.I set up a custom run configuration (thanks for explaining that), but when I run it, a couple of 'Permission denied' errors are generated, one apparently from execve, the other from fstat (unfortunately it does not seem to be possible to copy-and-paste from the terminal), so strace "exited with 1".
-
@aha_1980
I am able to build and run the examples, and also an application to test Qt3d functionality that I made from a couple of the examples.I set up a custom run configuration (thanks for explaining that), but when I run it, a couple of 'Permission denied' errors are generated, one apparently from execve, the other from fstat (unfortunately it does not seem to be possible to copy-and-paste from the terminal), so strace "exited with 1".
@gibbogle ok, so if the examples work, it must be your project.
Have you already wiped the build folder and .pro.user and rebuild your project?
Are you linking external libs?
Regards
-
@aha_1980
I am able to build and run the examples, and also an application to test Qt3d functionality that I made from a couple of the examples.I set up a custom run configuration (thanks for explaining that), but when I run it, a couple of 'Permission denied' errors are generated, one apparently from execve, the other from fstat (unfortunately it does not seem to be possible to copy-and-paste from the terminal), so strace "exited with 1".
@gibbogle said in Run environment in Qt Creator:
it does not seem to be possible to copy-and-paste from the terminal
It is possible: mark text in terminal and press Ctrl-Shift-c to copy (to paste into terminal use Ctrl-Shift-v). Or use context menu of your terminal.
-
@gibbogle ok, so if the examples work, it must be your project.
Have you already wiped the build folder and .pro.user and rebuild your project?
Are you linking external libs?
Regards
-
@gibbogle said in Run environment in Qt Creator:
it does not seem to be possible to copy-and-paste from the terminal
It is possible: mark text in terminal and press Ctrl-Shift-c to copy (to paste into terminal use Ctrl-Shift-v). Or use context menu of your terminal.
-
@jsulm
When I do Ctrl-Shift-c all that happens is a ^C is displayed.
I'm not sure what the context menu of the terminal is. If I right-click at the top I just get Minimize, Maximize, Move etc.@gibbogle said in Run environment in Qt Creator:
If I right-click at the top I just get Minimize
not at the top, but inside the terminal.
-
@gibbogle said in Run environment in Qt Creator:
If I right-click at the top I just get Minimize
not at the top, but inside the terminal.
wrote on 19 Sept 2019, 21:20 last edited by@jsulm
Sorry, I'm still not with you, right-click inside the terminal just highlights text. Is it possible that I have a different terminal program from your one? In the list of Applications on Ubuntu 18.04 I see XTerm and UXTerm. They both behave the same way. Do they need to be configured to have the behaviour you describe?
1/26