> On Jul 2, 2020, at 23:00, Pablo Rogina <pabl...@gmail.com> wrote:
>
> Hi, this is a follow up to my issue. I guess I found what's happening
> but I was not able to fix it...
>
> I did run an external gdb-multiarch remote debug session in MI mode
> using all the commands QtCreator passes to the debugger. However, I
> skipped the unset environment commands for all the env variables as
> QtCreator does, and the session run very well.
> Then I realized that one of the variables being unset by QtCreator is
> DISPLAY, so I repeated a new external gdb-multiarch remote session in
> MI mode, sending all the commands as QtCreator and unset environment
> variable DISPLAY and session crashes.
>
> And that behavior makes sense as I now realized that the same is
> happening when pressing F5, see the Output Application pane below, Qt
> app cannot connect to display since the env variable was unset.
>
> qt.qpa.xcb: could not connect to display
> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even
> though it was found.
>
> So looking in source code (src/plugins/debugger/gdb/gdbengine.cpp)
> method void GdbEngine::setEnvironmentVariables() there's a loop that
> sets or unsets every variable. But I couldn't understand what's the
> criteria for any variable to have operation as EnvironmentItem::Unset
This takes the difference between the host environment and the environment from
your “inferior” environment, which afaics should be the environment that you
see in the “Environment” part of your run configuration.
Environemnt variables in the host environment that are not in the inferior
environment, are unset.
Br, Eike
> if (item.operation == EnvironmentItem::Unset)
> runCommand({"unset environment " + name});
> else
> runCommand({"-gdb-set environment " + name + '=' + item.value});
>
> In addition, I tried adding set environment DISPLAY = :0 in the Attach
> Additional Commands but it has the same effect: app crashes since
> could not attach to display...
>
> Thanks. Pablo
>
> On Thu, Jul 2, 2020 at 12:17 PM Pablo Rogina <pabl...@gmail.com> wrote:
>>
>> Christian,
>>
>> again, by looking at the Application Output pane, where I can see
>> gdbserver starting on remote device, the port number, etc.
>> But mostly by the fact that the debug session for my Qt application
>> CRASHES since the xcb plugin isn't loaded.
>> So somehow even when the proper -exec-args command is sent from
>> QtCreator to the debugger is not being used or properly setup, I don't
>> know.
>>
>> On the other hand I am able to debug the same Qt app/device etc. by
>> using option Debug/Start Debugging/Attach to Running Debug Server or
>> if I run the debug session externally to QtCreator.
>> So I am confident that remote debugging for that Qt app with X
>> forwarding does work
>>
>> Thanks. Pablo
>>
>> On Thu, Jul 2, 2020 at 12:11 PM Christian Kandeler
>> <christian.kande...@qt.io> wrote:
>>>
>>> On Thu, 2 Jul 2020 09:37:51 -0300
>>> Pablo Rogina <pabl...@gmail.com> wrote:
>>>
>>>> I see. I'm not familiar with GDB/MI mode so that could be the right
>>>> approach then, but the end result at least for me is that the
>>>> arguments don't reach the remote program under debug
>>>
>>> Again, how do you know that?
>>>
>>>
>>> Christian
>>> _______________________________________________
>>> Qt-creator mailing list
>>> Qt-creator@qt-project.org
>>> https://lists.qt-project.org/listinfo/qt-creator
> _______________________________________________
> Qt-creator mailing list
> Qt-creator@qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator
