Unable to debug Android App (Windows + Qt Creator 12 + LLDB)
-
Yeah.. folks.. but tell you what....
We've been also using 5.15.2 previously for our project along with the Community version of Qt.
As you can imagine, a bit frustrated I was, so we bought a brand new Macbook with M2.
Everything works out of the box.
(..) with a damn Android VM.. even no need to attach a phone... the Android VM works crazy fast. Breakpoints keep spinning... no errors.... no assembly shit... no exceptions.. with out own project........
I'll give it a try with real device later on.
But presumably... all Qt user and development base moved to Apple hardware as of recent...
Spend 7 days from dawn till dusk fighting with Windows and Linux.
Buy a Macbook with M2 and have everything resolved.
I mean... breakpoints ARE not hitting within main(), but other than that? it's f*** PERFECT.
as if 100 bugs have been fixed. it simply works as it SHOULD.
Breakpoitns can be dynamically inserted, removed, these fire each time.
but yet again... not as soon as in main()
@CodesInChaoss
Thats good news, glad to hear!
May I ask you, which constellation works on the Mac?
Android SDK / NDB / ABI, Qt Creator & Qt Version?
That will help us to narrow down the issue and fix it asap.
Thanks in advance - and I hope you'll get some rest after 168 sleepless hours ;-) -
Yeah.. folks.. but tell you what....
We've been also using 5.15.2 previously for our project along with the Community version of Qt.
As you can imagine, a bit frustrated I was, so we bought a brand new Macbook with M2.
Everything works out of the box.
(..) with a damn Android VM.. even no need to attach a phone... the Android VM works crazy fast. Breakpoints keep spinning... no errors.... no assembly shit... no exceptions.. with out own project........
I'll give it a try with real device later on.
But presumably... all Qt user and development base moved to Apple hardware as of recent...
Spend 7 days from dawn till dusk fighting with Windows and Linux.
Buy a Macbook with M2 and have everything resolved.
I mean... breakpoints ARE not hitting within main(), but other than that? it's f*** PERFECT.
as if 100 bugs have been fixed. it simply works as it SHOULD.
Breakpoitns can be dynamically inserted, removed, these fire each time.
but yet again... not as soon as in main()
@CodesInChaoss I also moved from a Windows device to a MacBook Pro M1 Arm64 device. (I only had to change the keyboard to mimic Windows/Linux experience).
The best part is that you get a Arm64 Android VM, which is the aarch64 architecture that most Arm Android devices use.
Most likely the VM is faster than any Android Phone you can buy, since the Apple silicon is faster than what Qualcomm is putting out there (for now).
-
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 said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
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).The Small Business License is $499 per year per developer.
On QtWS23 there was an announcement from Qt Keynotes about some improvements in 2024: same price, higher revenue possible and - if I remember right - up to 5 tech support issues.
got an info, that this will be published in march or so. -
Yeah.. folks.. but tell you what....
We've been also using 5.15.2 previously for our project along with the Community version of Qt.
As you can imagine, a bit frustrated I was, so we bought a brand new Macbook with M2.
Everything works out of the box.
(..) with a damn Android VM.. even no need to attach a phone... the Android VM works crazy fast. Breakpoints keep spinning... no errors.... no assembly shit... no exceptions.. with out own project........
I'll give it a try with real device later on.
But presumably... all Qt user and development base moved to Apple hardware as of recent...
Spend 7 days from dawn till dusk fighting with Windows and Linux.
Buy a Macbook with M2 and have everything resolved.
I mean... breakpoints ARE not hitting within main(), but other than that? it's f*** PERFECT.
as if 100 bugs have been fixed. it simply works as it SHOULD.
Breakpoitns can be dynamically inserted, removed, these fire each time.
but yet again... not as soon as in main()
@CodesInChaoss said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
But presumably... all Qt user and development base moved to Apple hardware as of recent...
That hardware uses the ARMv8.6-A instruction set, which is what you'll find in most phones too. At least Android, I have no clue about iOs.
Which basically means that you're no longer debugging inside an (CPU) emulator, but basically doing it natively. And indeed I can understand that solves a host of issues.
I'm quite happy for you that this makes you're life a lot easier!
@ekkescorner said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
On QtWS23 there was an announcement
As someone that hasn't been in contact with sales since the Trolltech / Nokia days, I'm curious if customers "inform" Qtio about which platform they develop on. My thinking here is that if they have an actual insight into the revenue-stream for Android, management can calculate the profit/loss of paying a(nother) developer to in-house work on Android and actually use this stuff. Dogfooding and fixing issues.
I mean, issues like QTBUG-121561 are clearly the result of devs not having enough time for this stuff. It literally is the result of a bugfix being reverted and the old bug showing up again.
This thread shows similarly that dogfooding is not happening, unless Qt devs have no need to run a debugger. -
@CodesInChaoss I also moved from a Windows device to a MacBook Pro M1 Arm64 device. (I only had to change the keyboard to mimic Windows/Linux experience).
The best part is that you get a Arm64 Android VM, which is the aarch64 architecture that most Arm Android devices use.
Most likely the VM is faster than any Android Phone you can buy, since the Apple silicon is faster than what Qualcomm is putting out there (for now).
True.
Just wanted to update you folks that debugging latest real hardware Android devices from MacOS is impossible as well.
I ended up having the very same issues as on Windows.
Sigfaults and straight-into-assembly experience.
For now the best thing we came up with is debugging on Android Simulator running atop of M2.. but for now we cannot get around UDP data exchange limitations as our app uses UDT which runs atop of UDP and we are unable to maintain connectivity.
haven't managed to run on iOS simulator as well due to some strange error throwing which I would repost soon.
-
True.
Just wanted to update you folks that debugging latest real hardware Android devices from MacOS is impossible as well.
I ended up having the very same issues as on Windows.
Sigfaults and straight-into-assembly experience.
For now the best thing we came up with is debugging on Android Simulator running atop of M2.. but for now we cannot get around UDP data exchange limitations as our app uses UDT which runs atop of UDP and we are unable to maintain connectivity.
haven't managed to run on iOS simulator as well due to some strange error throwing which I would repost soon.
@CodesInChaoss
I fully understand, that the Android debugging issue at hand is frustrating. The only thing I can assure is that we are busily working to stabilize it again. You may want to look at the bugreport for some updates.Switching Ndk versions does change the debug behavior, so there is likely an external dependency as well. 25.1.8937393 has brought me a small improvement over 25.2...., albeit not a solution. It'll be helpful to know, which SDK / Ndk and Qt Creator versions are running on the M2 you have mentioned.
As regards your iOS simulator issue, feel free to post a separate thread and tag me. I've got a working environment here. Maybe I can help troubleshooting.
Software Engineer
The Qt Company, Oslo -
@CodesInChaoss
I fully understand, that the Android debugging issue at hand is frustrating. The only thing I can assure is that we are busily working to stabilize it again. You may want to look at the bugreport for some updates.Switching Ndk versions does change the debug behavior, so there is likely an external dependency as well. 25.1.8937393 has brought me a small improvement over 25.2...., albeit not a solution. It'll be helpful to know, which SDK / Ndk and Qt Creator versions are running on the M2 you have mentioned.
As regards your iOS simulator issue, feel free to post a separate thread and tag me. I've got a working environment here. Maybe I can help troubleshooting.
@Axel-Spoerl Just tested a simple group box example.
QtCreator 12.0.2
Ubuntu 22.04
Qt 6.6.2
JDK-17
NDK 21 or 25
Device: Samsung tablet A-8 with Android 13Problem 1: break into disassembler binary with JDK 17. The test case runs fine without breakpoints.
Problem 2: JDK 11 is not supported anymore. If JDK 11 and Qt 5.15.2 are applied, NDK can not be set-up. For Android 13, JDK 11 is the right selection. -
@Axel-Spoerl Just tested a simple group box example.
QtCreator 12.0.2
Ubuntu 22.04
Qt 6.6.2
JDK-17
NDK 21 or 25
Device: Samsung tablet A-8 with Android 13Problem 1: break into disassembler binary with JDK 17. The test case runs fine without breakpoints.
Problem 2: JDK 11 is not supported anymore. If JDK 11 and Qt 5.15.2 are applied, NDK can not be set-up. For Android 13, JDK 11 is the right selection. -
@JoeCFD
Does that mean, things break with JDK 17?@Axel-Spoerl Nope. No break stop in the code, instead in disassembler.
-
J JoeCFD referenced this topic on
-
At https://github.com/qt-creator/qt-creator/actions/runs/8161009528 I have artifacts for a fix for the Android debugger issue.
It's one line of code that brings Qt Creator 13 to the level of Qt Creator 10.
In my case of MacBook Pro M1 I am getting breakpoints hits and no longer "Waiting for debugger".
-
At https://github.com/qt-creator/qt-creator/actions/runs/8161009528 I have artifacts for a fix for the Android debugger issue.
It's one line of code that brings Qt Creator 13 to the level of Qt Creator 10.
In my case of MacBook Pro M1 I am getting breakpoints hits and no longer "Waiting for debugger".
-
@cristian-adam Good news. We have to use 13? No fix in 12?
@JoeCFD At https://wiki.qt.io/Qt_Creator_Releases there is no 12.0.3 release planed.
But, you can backport the change, is just one liner. Just clone Qt Creator on GitHub, cherry-pick the change and push a release tag to your fork. You will get releases automatically.
-
@JoeCFD At https://wiki.qt.io/Qt_Creator_Releases there is no 12.0.3 release planed.
But, you can backport the change, is just one liner. Just clone Qt Creator on GitHub, cherry-pick the change and push a release tag to your fork. You will get releases automatically.
https://download.qt.io/snapshots/qtcreator/13.0/13.0.0-rc1/78/ has the needed fixes for the working Android debugging.
-
https://download.qt.io/snapshots/qtcreator/13.0/13.0.0-rc1/78/ has the needed fixes for the working Android debugging.
-
@cristian-adam just downloaded it and had a try. The problem is still there.
Ubuntu 22.04
Qt 6.6.2
JDK-17
NDK 21 or 25@JoeCFD I just gave it a try on my MacBook Pro M1 with:
- Qt 6.6.1
- Android arm64-v8 emulator image
- Android SDK 33
- Android NDK 25
- OpenJDK-17
See the recording at qtcreator13-android33.mp4.
-
@JoeCFD I just gave it a try on my MacBook Pro M1 with:
- Qt 6.6.1
- Android arm64-v8 emulator image
- Android SDK 33
- Android NDK 25
- OpenJDK-17
See the recording at qtcreator13-android33.mp4.
@JoeCFD
Note the following:- if you have legacy break points, remove them all.
- if you want to set a break point into
main(), add aQThread::sleep(1)on top. It has to be the first instruction in main. - if you set no break points at all, the debugger will still jump to the disassembler. It looks as if the bug was still present. If you hit "continue" many times (18 in my case), the debuggee will start normally.
Software Engineer
The Qt Company, Oslo -
@JoeCFD
Note the following:- if you have legacy break points, remove them all.
- if you want to set a break point into
main(), add aQThread::sleep(1)on top. It has to be the first instruction in main. - if you set no break points at all, the debugger will still jump to the disassembler. It looks as if the bug was still present. If you hit "continue" many times (18 in my case), the debuggee will start normally.
I have tested the "dice" Qt example and I was able to land into "disassembly" only the first time that the application was installed on the device.
If I click continue it will skip all the SIGSEGVS and would hit my breakpoints.
See the recording: qtcreator13-disassembly.
The Java exceptions are implemented with signals and it looks like the
lldb-serveris picking up and giving them further down the chain.Android Studio users also have this problem see Android Studio keeps pausing with SIGSEGV (signal SIGSEGV: invalid address (fault address: 0x0)) at random [240007217] - Issue Tracker (google.com)
I have tried telling the debugger to ignore the signal:
process handle SIGSEGV --pass true --stop false --notify truebut it didn't work.
This doesn't look like a Qt Creator bug.
-
I have tested the "dice" Qt example and I was able to land into "disassembly" only the first time that the application was installed on the device.
If I click continue it will skip all the SIGSEGVS and would hit my breakpoints.
See the recording: qtcreator13-disassembly.
The Java exceptions are implemented with signals and it looks like the
lldb-serveris picking up and giving them further down the chain.Android Studio users also have this problem see Android Studio keeps pausing with SIGSEGV (signal SIGSEGV: invalid address (fault address: 0x0)) at random [240007217] - Issue Tracker (google.com)
I have tried telling the debugger to ignore the signal:
process handle SIGSEGV --pass true --stop false --notify truebut it didn't work.
This doesn't look like a Qt Creator bug.
As a workaround one can paste (plus Enter):
pro hand -p true -s false SIGSEGVIn the debugger console at the first assembly hit, and then all the rest are ignored!
-
I had luck with using ADB over Wi-Fi, debugging with QtCreator works at least once with ADB over Wi-Fi, in Android Studio debugging worked for me over USB and Wi-Fi, at least for a hello world app
EDIT: I take it back
@esnosy said in Unable to debug Android App (Windows + Qt Creator 12 + LLDB):
EDIT: I take it back
Does that mean, you are still struggling?
