AAPS dev 3.3.3.0 froze #3984
Comments
|
Got an other freeze to this night. Since last time I enabled everything to log as I don't know what can cause those freeze.
I just updated to latest dev this morning after the freeze, I will see if it happen again Edit : BG was back after a short time. |
No reason is visible in logs |
|
I experienced the same 2 times on (86fb), reboot of phone fixed it. Checked the logs and also no reason visible. It didnt crash, it just hung on the latest sate. (it showed last bg was 3 min ago, so upon checking first i didnt notice it was broken). I pulled latest commits and see if i can get a logcat dump when it happens again: Extras: |
|
It happened on older commit (f737) but nothing in log. Can't replicate issue as it is random. I'm on Android 15 (galaxy S23) |
|
Same here. No crash, just froze. No reaction to taps etc.
|
Only AAPS freezes - other apps and phone are then still responsive? |
|
Only AAPS, |
|
o meu AAPS 3.3.2.0 também trava. O comportamento dele é parecido com o LOOP Aberto. A quantidade de hidratos informada não diminui e as correções não acontecem. O problema é aleatório. Essa noite ele não fez uma única correção e amanheci com a glicemia alta, com 60g de hidratos que foram do meu jantar de ontem. Estava ativa somente a basal programada. Quando fui na aba SMB e atualizei ele gerou uma correção e aplicou, mas se não tivesse feito isso permaneceria congelado. Agora tomei meu café da manhã e parece que está funcionando o LOOP Fechado, mas se isso ficar acontecendo eu pensei em fazer um downgrade de versão, porque na 3.3.1 isso não acontecia. |
English please? |
|
My AAPS 3.3.2.0 also freezes. Its behavior is similar to Open Loop. The amount of carbs entered does not decrease, and corrections do not happen. The problem is random. Last night, it didn’t make a single correction, and I woke up with high blood sugar, with 60g of carbs remaining from my dinner yesterday. Only the programmed basal was active. When I went to the SMB tab and refreshed it, it generated a correction and applied it, but if I hadn’t done that, it would have remained frozen. Now I’ve had breakfast, and it looks like Closed Loop is working, but if this keeps happening, I’m considering downgrading the version because this didn’t happen in 3.3.1 |
|
Latest dev (86fb) froze again last night, will pull logs and add to this comment in an hour. Weird behaviour is that I force closed AAPS and relaunched, but xdrip values are not being processed by AAPS (xdrip itself works fine, AAPS is functional except receiving BG), that might be a clue in the right direction |
|
The same for me, xDrip had gotten all the BGs but they did NOT catch-up when AAPS was "force restarted". One explanation is : AAPS didn't totally froze as it continued "listening" to arriving BGs but never registered or acted on them. When forced restart, it didn't say, last BG was hours ago, I need to catch-up but said, "ok, last BG was 2 min ago, waiting the next". As it is NOT AAPS requesting BGs but xDrip sending them, and as xDrip sent normally all the past BGs, it just sends the next one when available. The other (and more probable) explanation is : (This needs testing) Does, a forced closed AAPS catch-up BGs (when started 15+ minutes later) or not ? Will test this today. My guess is that the BGs are missing in AAPS because xDrip had already sent them regularly and "doesn't care" if nobody was listening. |
This happened for me too, i went to the shower and when i got back (phone was in range all the time), AAPS started receiving BG's again. Here's my reconstruction
Logcat logs mentioning AAPS (unfortunately crash is out of retention period) froze_redacted_aaps_log.txt
|
|
Using BYODA and AAPS latest dev versions. My 2cts: (2) What is reported in this issue looks similar to what I experienced with BYODA some weeks ago after my Samsung S22 Ultra (running A14) received an OS update where Play Protect suddenly started to behave even much more aggressive. Until then I never had a need to switch it off. Shortly after, on updating AAPS, Play Protect threw a big pop-up. Ignored it and installed AAPS anyway. That night I experienced with AAPS which has a striking resemblance with the "freezing" reported here: No problem with BYODA/Dexcom which was receiving BG values as usual, but AAPS just stopped receiving BG values from BYODA and loop stopped. Could not find the problem so got through the night with just profile basals. Next morning it took me at least an hour to solve the problem:
Then I noticed under AAPS permissions, "additional permissions" it now showed the "Access Dexcom app". @MilosKozak @ALL Did any of you try uninstalling xDrip, restarting the phone and then reinstalling latest xDrip+ (assuming this would reset permissions)? |
|
Strange, I had that "App Additional permissions" line in AAPS permissions but when I checked right now, I can't see it. It was there for some time now and had receive data from xDrip (os sth similar) |
|
I'm using BYODA and i'm having same behavior randomly.
About Additionnal Persmissions it was a while since it is here (can't remember when I saw it) but it was already on for me. Using : Edit : No freeze since my report last week (or more) |
|
I'm in a freeze state right now, and am watching logcat for androidAPS, while the app hangs, i see a lot of these warnings pass by: These are logs from before and at the freeze (happening at 17:26) Pretty sure its related to the database connection failing for some reason Update 26-05 22:00: Froze again, same SQLiteConnectionPool error. Completely disabled play protect after last weeks freeze. Will now fully reinstall both Xdrip and AAPS to see if that solves anything, Oneui 7, android 15, samsung s21FE Update: Did a full reinstall, of xdrip and AAPS 3.3.3.0-dev (e2666), (i think we should really streamline the process of setting up permissions etc), when pulling all data from NS, i experienced a hang again and it was the same SQLiteConnectionPool error (i'll update this post as i try to debug whats happening) |
|
database overloading after full sync is resolved in dev |
|
@MilosKozak I had not done any full sync ( but my phone only uploads to NS (api v3) when charging at night) but had the freezes too. Didn't have any freezes for some days. Running dev built on 18/05. |
That's older commit form May 15th without the fix. Try latest? |
Yeah that was me not having my morning coffee yet, i pulled latest and am expieriencing instant freezes, this is what my logcat shows me:
Update: After a database reset this seems to happen during a NS full sync, the Queue numbers stopped going down (now going down very very slowly) when these logcat messages appear (40k entries remaining)
AAPS export is being corrupted. Update: Cleared database and synced NS(3) again:
temp workaround, not fully syncing NS (historical BG) last update (for this debug session): This is also my reproducable way: set everything up, without ns backsync (but with profile pull etc), everything works as expected, when i click full sync, ns sync goes through with a few "isn't responding" notifications because it's so busy with the NS entries, after the sync i get in a very slow state of the app with repeating "isnt responding" notifications, where logcat is wating for blocking GC Allocs. My suspicion now is that it's in the statistics calculation. Froze state can be reset by clearing the database and pulling everything from NS except historical BG data.
|
|
Update:... just realized I have been merging PR3968: Just installed current AAPS dev commit without merging PR3968 on my Nokia 5.4 test phone: it completely freezes (close app / wait pop-up) when trying a full NS sync.... When I then "close" AAPS, on reopen I can continue full sync successfully. Subsequent sync are experiencing som app freezing but eventually finish successfully also. Also noted during full sync queue is not used (at least UI shows "queue: n.a") So PR3968 fixes a problem that is in current dev? |
|
Solved my issue, in the database was a carbs entry with a duration of 216000000000 (default for unlimited). This caused the carbs.expand function to create loads of allocations, freezing my app:
Solved by running a debug version and removing the duration field of that carb entry |
Good find! |
|
Do you know how it happened? |
Been able to reproduce the issue now
My steps:
Solving this issue completely would likely require an overhaul of the database entry / sync mechanism to catch these occurrences, suggested fix in #4002 is a solution to prevent the app from freezing if it happens Managed to grab the logcat entries during import: |
|
I think i nailed it down to the exact issue @MilosKozak : On 2025-03-10 (when i was running a dev built on 03-03), something caused a Carb correction with the duration of 3600000 entry in my nightscout database (too far back to trace what caused this exactly, but it's there) The logic in ThreatmentMapper.kt: (if i understand it correctly) Which will: set durationinMilliseconds to durationInMilliseconds, which does not extist in the incoming document, so it'll take the duration (3600000) and convert it to milliseconds, maxing out the value to 216000000000 (max database value) Whenever i enter a new carb entry (dev branch), the duration gets set correctly to minutes, so it's likely a past issue which has been resolved already, but still lives in my nightscout database (again, was running build from 03-03 that time), there has been one commit related to handling this information in april: 9b90eea #3917
Ideally we would check this on importing before multiplying to milliseconds, but the proposed change is a simple and effective safeguard if this happens in the database |
|
Froze again this morning, around 6:25 AM. I'm on Android 15 OneUI 7.0 now.
|
|
When I look in the treatments tab, the only thing near 6:25 is this. And it is a bit strange, 14 min not 15 min !temp basal.
|
|
@robertrub by any chance are you able to pull a logcat from the time around the freeze? Adb.exe logcat > log.txt or in android studio in the left lower bottom (here you can filter for androidAPS which) Logcat doesn't go back in time very long, depending on how many logs often an hour or 2. |
|
One more hint, my phone was on the charging stand, at 6:25 I woke up and single or double tapped the screen to se the time and BG (shown byxDrip)... As for the logs, I sent the logs from AAPS and I think it's a bit late for the phone logs 😞 |
|
I see other "non 5 min" basal rate changes.
|
|
@jbr7rr this seems to be Medtrum pump or driver issue |
|
@robertrub Assuming you can do a repro of the freeze? Or is AAPS maybe also syncing/uploading data to xDrip+? @MilosKozak When debugging AAPS from Android Studio i use NS as BG source (config builder) while also downloading data from NSv3.
However, I noticed that when I reset the database and then do a full NSv3 resync it does not only back-sync all data from NS but at some point, it also starts syncing all data to the xDrip+ follower client. Android Studio debugger in logcat showed AAPS had a hard time keeping up, GC, mem swap and continuously complaining on "too much activity on main tread". After some time AAPS seemed to get what looked like a "freeze" while still receiving BG values? To get out, only way I found was stopping the app. Additional notes:
|
|
Hi @vanelsberg |
|
Hi @robertrub
Ok. I think the "freezing" you were reporting is a different one then mine: (1) this morning installed latest dev without merging the StateDB PR on my main phone. This required a database reset as I had been running with the PR for some time. Half way resyncing data from NS, AAPS looked up with the wait/close pop-up. Waiting did not solve so exit AAPS. On restart it was fine, so after letting it stabilize for a few minutes tried a full resync again. 2nd resync completed where it left off successfully. (2) Apart from above, I did experience a "freeze" that is similar to what you described twice: |
In my several freeze cases, AAPS didn't just stop receiving BG values, it also did NOT react to any taps etc. The UI (or the full app) was dead or frozen. |
OK, so now to me this gets complicated with 3 different "freeze" situations 😕
Now question is, are these different, or maybe somehow related? |
This happened several times. I look at AAPS and find out that is has frozen during the night.
I thought that it was related to Play Protect but it froze again this morning (a bit before 7 AM) and Play protect is OFF.
As you can see, there was a "catch-up" in BGs when I force closed, cleared cache and restarted AAPS.
The logs after force close and restart.
The text was updated successfully, but these errors were encountered: