Unable to debug Android App (Windows + Qt Creator 12 + LLDB)
-
It's like I'm debugging on V8 ABI, I need 64 bit compiler and QT Creator keeps reverting settings back to 32bit compiled actually messing up with my settings.
Now, how a regular developer is even to notice?
By the time I reconfigured everything, it turns our Creator is unable to attach due to ADB being in an 'incompatible state. Thus I'm best off restarting the PC...
-
By the time I reconfigured everything, it turns our Creator is unable to attach due to ADB being in an 'incompatible state. Thus I'm best off restarting the PC...
otherwise it would just remain stuck at ```
D libGRIDNEToken_arm64-v8a.so: QML Debugger: Waiting for connection on port 51672...forever -
otherwise it would just remain stuck at ```
D libGRIDNEToken_arm64-v8a.so: QML Debugger: Waiting for connection on port 51672...foreverI'm also getting segmentation faults in 'binder:X' threads on UI interactions.
Yet again, if I ignore these the app runs FINE.
ideas?
It's like tapping on an UI element is almost guaranteed to result in such a SigFault.
-
I'm also getting segmentation faults in 'binder:X' threads on UI interactions.
Yet again, if I ignore these the app runs FINE.
ideas?
It's like tapping on an UI element is almost guaranteed to result in such a SigFault.
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
I'm also getting segmentation faults in 'binder:X' threads on UI interactions.
Yet again, if I ignore these the app runs FINE.
ideas?
It's like tapping on an UI element is almost guaranteed to result in such a SigFault.
The moment one pastes anything to
QT Creator crashed, Lo and Behold
On my way to reconfigure everything anew.
this feels like an early Alpha of some wanna-be development framework not something that has been around for many many years.
Something I paid for.
-
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
I'm also getting segmentation faults in 'binder:X' threads on UI interactions.
Yet again, if I ignore these the app runs FINE.
ideas?
It's like tapping on an UI element is almost guaranteed to result in such a SigFault.
The moment one pastes anything to
QT Creator crashed, Lo and Behold
On my way to reconfigure everything anew.
this feels like an early Alpha of some wanna-be development framework not something that has been around for many many years.
Something I paid for.
@CodesInChaoss I am pretty sure that it is mostly related to the update process
-
@CodesInChaoss I am pretty sure that it is mostly related to the update process
yeah sure but for the fact I've wiped out everything QT related.
- QT has been wiped CLEAN the entire QT folder
- everything in AppData QT related WIPED clean as well.
- NDK/ SDK everything installed anew
- same stuff on a fresh VM (like I've explaiend)
-
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
I'm also getting segmentation faults in 'binder:X' threads on UI interactions.
Yet again, if I ignore these the app runs FINE.
ideas?
It's like tapping on an UI element is almost guaranteed to result in such a SigFault.
The moment one pastes anything to
QT Creator crashed, Lo and Behold
On my way to reconfigure everything anew.
this feels like an early Alpha of some wanna-be development framework not something that has been around for many many years.
Something I paid for.
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
Something I paid for.
If you mean you have purchased a commercial licence from TQtC you can raise your issues with them for their attention.
If you are using the free, open source version then that is not available and here we are just other users of Qt like yourself.
-
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
Something I paid for.
If you mean you have purchased a commercial licence from TQtC you can raise your issues with them for their attention.
If you are using the free, open source version then that is not available and here we are just other users of Qt like yourself.
We've bought the 'cheap' startup license or I recall 600USD per year per person.
Now, it does not come with technical support (as it tuned out).
As we've learned the hard way that is.
Now, I've forced GDB manually to neglect any segmentation faults (!!!) and Sig33s (..) by typing the custom arguments to QT Creator by hand as copy-pasting would result it to CRASH.
Now I'm able to debug.. I'm not disturbed by QT's internal segmentation faults... I presume? correct me if I'm wrong
-
We've bought the 'cheap' startup license or I recall 600USD per year per person.
Now, it does not come with technical support (as it tuned out).
As we've learned the hard way that is.
Now, I've forced GDB manually to neglect any segmentation faults (!!!) and Sig33s (..) by typing the custom arguments to QT Creator by hand as copy-pasting would result it to CRASH.
Now I'm able to debug.. I'm not disturbed by QT's internal segmentation faults... I presume? correct me if I'm wrong
Something I haven't seen for like 4 years
-
We've bought the 'cheap' startup license or I recall 600USD per year per person.
Now, it does not come with technical support (as it tuned out).
As we've learned the hard way that is.
Now, I've forced GDB manually to neglect any segmentation faults (!!!) and Sig33s (..) by typing the custom arguments to QT Creator by hand as copy-pasting would result it to CRASH.
Now I'm able to debug.. I'm not disturbed by QT's internal segmentation faults... I presume? correct me if I'm wrong
@CodesInChaoss
Ah, I did not know about that licence's terms.I'm not sure whether in "QT's internal segmentation faults" you mean Qt itself or Qt Creator. I would be worried about either, certainly if Qt code itself in your application is faulting, but I don't know what "workarounds" you need/have to live with for your situation.
Be aware that even without paid support you can raise bugs, against either Qt or Creator, at https://bugreports.qt.io/. People there look at them and respond/fix, regardless of OP's license state. I think Creator is regularly undergoing new releases, I don't know how robust it is for Android stuff.
-
@CodesInChaoss
Ah, I did not know about that licence's terms.I'm not sure whether in "QT's internal segmentation faults" you mean Qt itself or Qt Creator. I would be worried about either, certainly if Qt code itself in your application is faulting, but I don't know what "workarounds" you need/have to live with for your situation.
Be aware that even without paid support you can raise bugs, against either Qt or Creator, at https://bugreports.qt.io/. People there look at them and respond/fix, regardless of OP's license state. I think Creator is regularly undergoing new releases, I don't know how robust it is for Android stuff.
yes yes yes dear friend I know... I've been raising bugs from a different account for years ... we've all been developing QT since then kicked us in the ass years ago and run away with source code.
I know I can.
Then I get to wait 1-2 years till fix-ups make their way into commercial license and another 2 years into open source.
I know.
-
yes yes yes dear friend I know... I've been raising bugs from a different account for years ... we've all been developing QT since then kicked us in the ass years ago and run away with source code.
I know I can.
Then I get to wait 1-2 years till fix-ups make their way into commercial license and another 2 years into open source.
I know.
As of now
- we are manually overriding QT's Segmentation Fault events
- overriding Sig33 signals (bionic hardware)
Under the above conditions we are able to debug through QT Creator 12 and GDB with Qt 5.15.16 BUT
- removal of any breakpoint causes the GDB connection to become corrupted.
- no further debugging would be possible
Anyway, we CAN live with that (hopefully).
The most pressing issue is - how to force the mobile app to actually wait for QT Creator to fully attach?
I don't know the details but it seems that QT Creator 12 attached through GDB, the app knows.. BUT... NO BREAKPOINTS WOULD FIRE FOR 2-3 minutes at all (creator would keep showing that it's still attaching during that time period).
-
As of now
- we are manually overriding QT's Segmentation Fault events
- overriding Sig33 signals (bionic hardware)
Under the above conditions we are able to debug through QT Creator 12 and GDB with Qt 5.15.16 BUT
- removal of any breakpoint causes the GDB connection to become corrupted.
- no further debugging would be possible
Anyway, we CAN live with that (hopefully).
The most pressing issue is - how to force the mobile app to actually wait for QT Creator to fully attach?
I don't know the details but it seems that QT Creator 12 attached through GDB, the app knows.. BUT... NO BREAKPOINTS WOULD FIRE FOR 2-3 minutes at all (creator would keep showing that it's still attaching during that time period).
We may add a Sleep for 5 minutes.. in the initial main() loop
but come on folks.. that is not the way we are supposed to work... is it
-
We may add a Sleep for 5 minutes.. in the initial main() loop
but come on folks.. that is not the way we are supposed to work... is it
I System.out: Debugger has connected I System.out: waiting for debugger to settle... I System.out: waiting for debugger to settle... I System.out: debugger detached?that's also present when debugging with GDB.
-
I System.out: Debugger has connected I System.out: waiting for debugger to settle... I System.out: waiting for debugger to settle... I System.out: debugger detached?that's also present when debugging with GDB.
Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"?The index cache directory name is empty, skipping store. The index cache directory name is empty, skipping store. The index cache directory name is empty, skipping store. Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. -
Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"?The index cache directory name is empty, skipping store. The index cache directory name is empty, skipping store. The index cache directory name is empty, skipping store. Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code.AFTER disabling
- wait for debugger in Android Developer Settings (on mobile)
AND - after REMOVING the debugged application from the list of debugged applications ON ANDROID DEVICE
we are able to get have breakpoints working WAY SOONER (!!!)
now that i strange on the grounds of its own, is it not.....but STILL unable to have breakpoints at main() stage working at all.
Yet again we are talking about QT Creator 12 + GDB + Qt 5.15.16 (LTS)
so the pressing issues are
- get to know how to break as soon as in main() - normal thing to be expected
- what the heck are sig-faults in Qt related code?
- wait for debugger in Android Developer Settings (on mobile)
-
AFTER disabling
- wait for debugger in Android Developer Settings (on mobile)
AND - after REMOVING the debugged application from the list of debugged applications ON ANDROID DEVICE
we are able to get have breakpoints working WAY SOONER (!!!)
now that i strange on the grounds of its own, is it not.....but STILL unable to have breakpoints at main() stage working at all.
Yet again we are talking about QT Creator 12 + GDB + Qt 5.15.16 (LTS)
so the pressing issues are
- get to know how to break as soon as in main() - normal thing to be expected
- what the heck are sig-faults in Qt related code?
so seems like nobody (as usually) can assist around here even in questions regarding basic debugging.... this community is such a shame...
- wait for debugger in Android Developer Settings (on mobile)
-
so seems like nobody (as usually) can assist around here even in questions regarding basic debugging.... this community is such a shame...
@CodesInChaoss Maybe try to do it on Linux and it could be easier. The executable is same.
-
so seems like nobody (as usually) can assist around here even in questions regarding basic debugging.... this community is such a shame...
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
so seems like nobody (as usually) can assist around here even in questions regarding basic debugging.... this community is such a shame
A lot of lazy devs here ;-)
I'm especially interested in Qt because of its cross-platform ability. I do 90% of my android development in a native compile, with a window on my desktop. Have had maybe once or twice the wish to have a debugger for my remote Android device, but never found it important enough to install the tools for that. Qt Android tools are too freaking huge.
So, I'm lazy and debug on the native app on my desktop. Then do testing on the device, which rarely gives me issues I could not see on the desktop.
Not saying that what you want is wrong or anything like that. If QtCreator tells you that breakpoints should work, then they should work. And a paying customer should be able to demand attention from the Qt company.
I'm not a paying customer, no support for me.
Plenty of problems with the new Qt company of the last years, gerrit sucks. Jira even more so. As an open source programmer I have zero incentive to report bugs for the LTS releases since I'd wait at minimum a full year for a bugfix. And the quality is just really quite sad for Android. But it still is better than most alternatives I've tried. So here we are :-) -
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
so seems like nobody (as usually) can assist around here even in questions regarding basic debugging.... this community is such a shame
A lot of lazy devs here ;-)
I'm especially interested in Qt because of its cross-platform ability. I do 90% of my android development in a native compile, with a window on my desktop. Have had maybe once or twice the wish to have a debugger for my remote Android device, but never found it important enough to install the tools for that. Qt Android tools are too freaking huge.
So, I'm lazy and debug on the native app on my desktop. Then do testing on the device, which rarely gives me issues I could not see on the desktop.
Not saying that what you want is wrong or anything like that. If QtCreator tells you that breakpoints should work, then they should work. And a paying customer should be able to demand attention from the Qt company.
I'm not a paying customer, no support for me.
Plenty of problems with the new Qt company of the last years, gerrit sucks. Jira even more so. As an open source programmer I have zero incentive to report bugs for the LTS releases since I'd wait at minimum a full year for a bugfix. And the quality is just really quite sad for Android. But it still is better than most alternatives I've tried. So here we are :-)^------ what a F***** joke.... talked with a QT lady over phone today they ask for 3800 EURO a year (per seat) for a license with Technical Support
