App crash when updating ratings on random files

[naso]

Hi there,

I've seen something similar already being listed on Trellos Bug Listings. Whenever I'm playing music and and try to update ratings on files being in the playlist, after third or fourth file was updated after clicking OK App immediately freezes, stops playing and is unresponsive until killing the process and restarting it. This happens indeed every single time when updating ratings on more than two or three files. Using app version 3.28 on Samsung Galaxy S10 with Custom Rom. If I can help with providing anything please tell me.

All the best,
Ben

[GoneMAD]

reproduce the issue and generate a logcat

gonemadmusicplayer.blogspot.com/2014/07/how-to-get-logcat-system-log-to-help.html

[naso]

Mar 14, 2022 9:25:32 GMT -5 GoneMAD said:

reproduce the issue and generate a logcat

gonemadmusicplayer.blogspot.com/2014/07/how-to-get-logcat-system-log-to-help.html

Alright, will do later on today. Though I'm not rooted on my custom rom, so it will just be an app logcat, not a system wide one.

Ben

[GoneMAD]

android 4.2 and newer doesnt require root. If you are getting crashes, the system one is most likely needed which is whats returned when you use the "take bug report" in the developer menu

App crashes are typically logged by the system (since the app itself crashes and cannot self log)

Also note that I do not officially support custom roms, meaning im unable to dedicate any significant time writing custom solutions for issues only present on custom roms. I will certainly look at logs and make any quick fixes if possible

[naso]

OK, I just found out it only happens whilst connected to a bluetooth device, which I am most of the time so I didn't realize earlier. Trying to find out if its just my BL headphones or generally any BL device. Will send promised logcat then tomorrow.

Ben

[naso]

Mar 15, 2022 9:47:49 GMT -5 GoneMAD said:

Also note that I do not officially support custom roms, meaning im unable to dedicate any significant time writing custom solutions for issues only present on custom roms. I will certainly look at logs and make any quick fixes if possible

Thanks for your explanations. And most certainly I would never expect any developer doing a custom fix for me, please. Though so far I don't think I've had a single bug notice yet (which I give quite frequently) which referred to the ROM I'm using (which is a pretty standard lineage rom).
Anyway, the current issue seems to turn out being a bluetooth stack one, we'll see.

Ben

[naso]

Hello,

after many attempts I managed to reproduce the crash and sent the bugreport to you.

Google Mailer Demon blocked my mail because "virus/suspect content found" which meant the attachment. After I renamed the zip-file to "bugreport.zip" it seemed to work.

Thanks for your efforts,
Ben

[GoneMAD]

got it. ended up in my spam filter

[naso]

Hello, did you get my email with attached logcat two or three days ago? No rush, just want to assure you got the information. Edit: ah, just saw your little post stating you got my mail, sorry I didn't see it before.

On another matter: I just did some bulk tagging, exchanging one character on 444 files adding up to 38 albums. After maybe ten seconds the foreground process crashed, but the actual worker process kept processing the task until it finished. It seemed to lock the foreground process as I wasn't able to restart the app before it had finished its task.

I'm pretty dumb when it comes to programming and don't know much about anything, so maybe you could be so kind helping me to make me understand why it's so hard to get an app like that stable - also with bulk editing maybe 5000 files at once. Considering the amount of RAM and raw processing power we have at our disposal, what's the business there compared to maybe Windows, where I can bulk edit a million files if I want still pretty stable. Would be great if you could light me up, thank you!

Ben

[GoneMAD]

yeah.. see previous post:

"got it. ended up in my spam filter"

[MotleyGord]

Mar 19, 2022 13:15:38 GMT -5 naso said:

On another matter: I just did some bulk tagging, exchanging one character on 444 files adding up to 38 albums. After maybe ten seconds the foreground process crashed, but the actual worker process kept processing the task until it finished. It seemed to lock the foreground process as I wasn't able to restart the app before it had finished its task.

Do you mean in GMMP you did a bulk edit for 444 files? This is not really ideal for a mobile device. Access to the files for writing is slow, especially if you are restricted by the newer SAF platform by Google (Android 11+).

Mar 19, 2022 13:15:38 GMT -5 naso said:

I'm pretty dumb when it comes to programming and don't know much about anything, so maybe you could be so kind helping me to make me understand why it's so hard to get an app like that stable - also with bulk editing maybe 5000 files at once. Considering the amount of RAM and raw processing power we have at our disposal, what's the business there compared to maybe Windows, where I can bulk edit a million files if I want still pretty stable. Would be great if you could light me up, thank you!

I would highly recommend you make your edits on your PC, then copy these over to your mobile device (or SD card). First this will make sure your main library files are updated as desired. Plus you can back up from there easily. And second, as you have already expressed above, the write speed on most mobile devices is pretty slow.

[GoneMAD]

The UI doesn't lock for anything. Everything is asynchronous from the UI. Tag edits are even more detached from the app / UI. They are edited through the work manager jobs

edit: Another thing to keep in mind that android is fairly aggressive on killing apps that use a lot of resources. Be sure to disable any power saving features for gmmp or "battery optimizer apps".

If the actual UI is dying i would guess its a resource thing. The work manager will restart / resume its jobs if they crash which is why it would have finished

[GoneMAD]

So it looks like its just some OS level / android sdk crash. This is not in my code


3-17 00:53:48.875 10519 28327 28327 I crash_dump64: performing dump of process 21884 (target tid = 16725)
03-17 00:53:48.881 10519 28327 28327 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : LineageOS Version: '18.1-20210308-UNOFFICIAL-beyond1lte'
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : Build fingerprint: 'samsung/beyond1ltexx/beyond1:10/QP1A.190711.020/G973FXXS9DTK9:user/release-keys'
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : Revision: '26'
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : ABI: 'arm64'
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : Timestamp: 2022-03-17 00:53:48+0100
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : pid: 21884, tid: 16725, name: RenderThread  >>> gonemad.gmmp <<<
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : uid: 10519
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
03-17 00:53:48.882 10519 28327 28327 F DEBUG   : Abort message: 'Failed to set damage region on surface 0x71ae622c80, error=EGL_BAD_ACCESS'
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x0  0000000000000000  x1  0000000000004155  x2  0000000000000006  x3  00000070ca1b00b0
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x4  00000073d4d7a000  x5  00000073d4d7a000  x6  00000073d4d7a000  x7  0000000000e16528
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x8  00000000000000f0  x9  4811f336acb3c100  x10 0000000000000000  x11 ffffffc0fffffbdf
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x12 0000000000000001  x13 000000006232788c  x14 002fc18a677082da  x15 0000442c5fb069a6
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x16 00000073d03d3c80  x17 00000073d03b5950  x18 00000070c9e18000  x19 000000000000557c
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x20 0000000000004155  x21 00000000ffffffff  x22 000000713def51af  x23 0000000000000009
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x24 000000713ded5007  x25 0000000000000001  x26 000000713deebf5c  x27 000000713e4e2000
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     x28 000000715e523960  x29 00000070ca1b0130
03-17 00:53:48.882 10519 28327 28327 F DEBUG   :     lr  00000073d03680ec  sp  00000070ca1b0090  pc  00000073d0368118  pst 0000000000000000
03-17 00:53:48.909 10519 28327 28327 F DEBUG   : backtrace:
03-17 00:53:48.909 10519 28327 28327 F DEBUG   :       #00 pc 000000000004e118  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: fa8b451fd81bd3a4b793dfd0dae7726c)
03-17 00:53:48.909 10519 28327 28327 F DEBUG   :       #01 pc 00000000005505e4  /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2256) (BuildId: 038f2b3708992120ecac73b75cd97f2c)
03-17 00:53:48.909 10519 28327 28327 F DEBUG   :       #02 pc 0000000000013978  /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+76) (BuildId: 5ddeb405cbf5aa6e6ee96e6f09211cdd)
03-17 00:53:48.909 10519 28327 28327 F DEBUG   :       #03 pc 0000000000006e0c  /system/lib64/liblog.so (__android_log_assert+336) (BuildId: 1746fd6163606cd33152e38d831e02bc)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #04 pc 0000000000221370  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::damageFrame(android::uirenderer::renderthread::Frame const&, SkRect const&)+268) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #05 pc 00000000002144f0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::draw(android::uirenderer::renderthread::Frame const&, SkRect const&, SkRect const&, android::uirenderer::LightGeometry const&, android::uirenderer::LayerUpdateQueue*, android::uirenderer::Rect const&, bool, android::uirenderer::LightInfo const&, std::__1::vector<android::sp<android::uirenderer::RenderNode>, std::__1::allocator<android::sp<android::uirenderer::RenderNode> > > const&, android::uirenderer::FrameInfoVisualizer*)+80) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #06 pc 000000000021d354  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+540) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #07 pc 000000000021f814  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+480) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #08 pc 000000000020e28c  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+220) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #09 pc 000000000022f130  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+88) (BuildId: e70c6760ee993fab8a6b5dc1b4d1e5ee)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #10 pc 0000000000015400  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+260) (BuildId: ace7d6d390115ff375f0cc77d9807dfe)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #11 pc 0000000000014cc4  /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+412) (BuildId: ace7d6d390115ff375f0cc77d9807dfe)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #12 pc 00000000000b0db8  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: fa8b451fd81bd3a4b793dfd0dae7726c)
03-17 00:53:48.910 10519 28327 28327 F DEBUG   :       #13 pc 000000000005004c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: fa8b451fd81bd3a4b793dfd0dae7726c)
03-17 00:53:48.920 10219  7164 13338 D skia    : --- Failed to create image decoder with message 'unimplemented'


A quick google of the "Failed to set damage region on surface" error did have one post that mentioned something about having too many files open. I'll verify the tag edits are closing the file after the edit, otherwise this looks like an OS bug that doesnt have any resolution (i dont see any status on the google bug trackers either)