Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Memory usage grows on Android, possible memory leak #121

Open
prechtelm opened this issue Jan 27, 2021 · 35 comments
Open

Memory usage grows on Android, possible memory leak #121

prechtelm opened this issue Jan 27, 2021 · 35 comments

Comments

@prechtelm
Copy link

Hi,
after some runtime (2 - 8h) the app crashes with the following error. Looks like a native crash in libvosk_jni.so. How can we fix that issue?

2021-01-27 10:34:06.666 ? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2021-01-27 10:34:06.666 ? A/DEBUG: Build fingerprint: 'Android/rk3288/rk3288:7.1.2/TEST/ROM-20190802:userdebug/test-keys'
2021-01-27 10:34:06.666 ? A/DEBUG: Revision: '0'
2021-01-27 10:34:06.666 ? A/DEBUG: ABI: 'arm'
2021-01-27 10:34:06.666 ? A/DEBUG: pid: 24511, tid: 29658, name: Thread-280 >>> de.mytest.app <<<
2021-01-27 10:34:06.666 ? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2021-01-27 10:34:06.675 ? A/DEBUG: Abort message: '/buildbot/src/android/ndk-release-r21/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:72: abort_message: assertion "terminating with uncaught exception of type std::bad_alloc: std::bad_alloc" failed'
2021-01-27 10:34:06.675 ? A/DEBUG: r0 00000000 r1 000073da r2 00000006 r3 00000008
2021-01-27 10:34:06.675 ? A/DEBUG: r4 5d97f978 r5 00000006 r6 5d97f920 r7 0000010c
2021-01-27 10:34:06.675 ? A/DEBUG: r8 6f3b8bad r9 00a00000 sl a9ca1008 fp 00100000
2021-01-27 10:34:06.675 ? A/DEBUG: ip 0000000c sp 5d97e858 lr a9c5b857 pc a9c5e0c0 cpsr 600f0010
2021-01-27 10:34:06.710 ? A/DEBUG: backtrace:
2021-01-27 10:34:06.710 ? A/DEBUG: #00 pc 0004a0c0 /system/lib/libc.so (tgkill+12)
2021-01-27 10:34:06.710 ? A/DEBUG: #1 pc 00047853 /system/lib/libc.so (pthread_kill+34)
2021-01-27 10:34:06.710 ? A/DEBUG: #2 pc 0001d8b5 /system/lib/libc.so (raise+10)
2021-01-27 10:34:06.710 ? A/DEBUG: #3 pc 00019401 /system/lib/libc.so (__libc_android_abort+34)
2021-01-27 10:34:06.710 ? A/DEBUG: #4 pc 00017048 /system/lib/libc.so (abort+4)
2021-01-27 10:34:06.710 ? A/DEBUG: #5 pc 0001b8b3 /system/lib/libc.so (__libc_fatal+22)
2021-01-27 10:34:06.710 ? A/DEBUG: #6 pc 000195fb /system/lib/libc.so (__assert2+18)
2021-01-27 10:34:06.710 ? A/DEBUG: #7 pc 006f7ddf /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so
2021-01-27 10:34:06.710 ? A/DEBUG: #8 pc 006f7ee1 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so
2021-01-27 10:34:06.710 ? A/DEBUG: #9 pc 006f64a1 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so
2021-01-27 10:34:06.710 ? A/DEBUG: #10 pc 006f5d4f /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so
2021-01-27 10:34:06.710 ? A/DEBUG: #11 pc 006f5d17 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (__cxa_throw+74)
2021-01-27 10:34:06.710 ? A/DEBUG: #12 pc 006f09d3 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_Znwj+54)
2021-01-27 10:34:06.711 ? A/DEBUG: #13 pc 00260b13 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (ZN3fst21CompactHashStateTableINS_24DefaultComposeStateTupleIiNS_15PairFilterStateINS2_INS_18IntegerFilterStateIaEENS_17WeightFilterStateINS_17TropicalWeightTplIfEEEEEENS3_IiEEEEEENS_11ComposeHashISC_EEE9FindStateERKSC+166)
2021-01-27 10:34:06.711 ? A/DEBUG: #14 pc 002602f5 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN3fst8internal14ComposeFstImplINS_17DefaultCacheStoreINS_6ArcTplINS_17TropicalWeightTplIfEEEEEENS_23PushLabelsComposeFilterINS_24PushWeightsComposeFilterINS_22LookAheadComposeFilterINS_24AltSequenceComposeFilterINS_16LookAheadMatcherINS_3FstIS6_EEEESF_EESF_SF_LNS_9MatchTypeE3EEESF_SF_LSH_3EEESF_SF_LSH_3EEENS_24GenericComposeStateTableIS6_NS_15PairFilterStateINSM_INS_18IntegerFilterStateIaEENS_17WeightFilterStateIS5_EEE
2021-01-27 10:34:06.711 ? A/DEBUG: #15 pc 0025ff21 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN3fst8internal14ComposeFstImplINS_17DefaultCacheStoreINS_6ArcTplINS_17TropicalWeightTplIfEEEEEENS_23PushLabelsComposeFilterINS_24PushWeightsComposeFilterINS_22LookAheadComposeFilterINS_24AltSequenceComposeFilterINS_16LookAheadMatcherINS_3FstIS6_EEEESF_EESF_SF_LNS_9MatchTypeE3EEESF_SF_LSH_3EEESF_SF_LSH_3EEENS_24GenericComposeStateTableIS6_NS_15PairFilterStateINSM_INS_18IntegerFilterStateIaEENS_17WeightFilterStateIS5_EEE
2021-01-27 10:34:06.711 ? A/DEBUG: #16 pc 0025e4c9 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN3fst8internal14ComposeFstImplINS_17DefaultCacheStoreINS_6ArcTplINS_17TropicalWeightTplIfEEEEEENS_23PushLabelsComposeFilterINS_24PushWeightsComposeFilterINS_22LookAheadComposeFilterINS_24AltSequenceComposeFilterINS_16LookAheadMatcherINS_3FstIS6_EEEESF_EESF_SF_LNS_9MatchTypeE3EEESF_SF_LSH_3EEESF_SF_LSH_3EEENS_24GenericComposeStateTableIS6_NS_15PairFilterStateINSM_INS_18IntegerFilterStateIaEENS_17WeightFilterStateIS5_EEE
2021-01-27 10:34:06.711 ? A/DEBUG: #17 pc 0025417f /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZNK3fst10ComposeFstINS_6ArcTplINS_17TropicalWeightTplIfEEEENS_17DefaultCacheStoreIS4_EEE15InitArcIteratorEiPNS_15ArcIteratorDataIS4_EE+106)
2021-01-27 10:34:06.711 ? A/DEBUG: #18 pc 00264197 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN3fst8internal13ArcMapFstImplINS_6ArcTplINS_17TropicalWeightTplIfEEEES5_NS_28RemoveSomeInputSymbolsMapperIS5_iEEE6ExpandEi+122)
2021-01-27 10:34:06.711 ? A/DEBUG: #19 pc 002635dd /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZNK3fst9ImplToFstINS_8internal13ArcMapFstImplINS_6ArcTplINS_17TropicalWeightTplIfEEEES6_NS_28RemoveSomeInputSymbolsMapperIS6_iEEEENS_3FstIS6_EEE16NumInputEpsilonsEi+90)
2021-01-27 10:34:06.711 ? A/DEBUG: #20 pc 002d5ecc /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN5kaldi23LatticeFasterDecoderTplIN3fst3FstINS1_6ArcTplINS1_17TropicalWeightTplIfEEEEEENS_7decoder16BackpointerTokenEE18ProcessNonemittingEf+1176)
2021-01-27 10:34:06.711 ? A/DEBUG: #21 pc 002d37f4 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN5kaldi23LatticeFasterDecoderTplIN3fst3FstINS1_6ArcTplINS1_17TropicalWeightTplIfEEEEEENS_7decoder16BackpointerTokenEE15AdvanceDecodingEPNS_18DecodableInterfaceEi+312)
2021-01-27 10:34:06.711 ? A/DEBUG: #22 pc 0023ce9f /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN15KaldiRecognizer14AcceptWaveformERN5kaldi6VectorIfEE+126)
2021-01-27 10:34:06.711 ? A/DEBUG: #23 pc 0023cddf /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (_ZN15KaldiRecognizer14AcceptWaveformEPKci+130)
2021-01-27 10:34:06.711 ? A/DEBUG: #24 pc 002a5549 /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (vosk_recognizer_accept_waveform+4)
2021-01-27 10:34:06.711 ? A/DEBUG: #25 pc 002395ed /data/app/de.mytest.app-2/lib/arm/libvosk_jni.so (Java_org_kaldi_VoskJNI_KaldiRecognizer_1AcceptWaveform+38)
2021-01-27 10:34:06.712 ? A/DEBUG: #26 pc 004700db /data/app/de.mytest.app-2/oat/arm/base.odex (deleted) (offset 0x42de000)
@nshmyrev
Copy link
Collaborator

std::bad_alloc means it goes out of memory. Does it leak memory in your case somehow? Do you have extra things in your app that leak memory?

@prechtelm
Copy link
Author

I'm afraid not. Could restart of vosk after X minutes resolve the issue?

@nshmyrev
Copy link
Collaborator

You'd better figure out where you leak the memory. Maybe you create many models instead of single one.

@nshmyrev
Copy link
Collaborator

Can you reproduce this issue with our demo?

@prechtelm
Copy link
Author

After intensive testing, app is not leaking. Memory looks rock solid without vosk.
With vosk active native memory allocation increases steadily. 20 - 50 mb per 10 minutes. Only one model is loaded. That looks like a leak in vosk?

@sokolyaka
Copy link

I can reproduce the same issue using your demo application.

The first time when I noticed that the memory allocation increases steadily, was in my own application where I added the VOSK (with the English model) as the STT engine for constant listening. If I use it in a noisy environment I have a crash (because of the out-of-memory case) in around two hours. I profiled the application and noticed that the native memory allocation increased steadily. When I use the same application using the Google Cloud STT engine I don't have the memory issue.
After I have figured out the issue I decided to check if I use VOSK lib in the correct way, cloned and run the demo application on my device, profiled it, and noticed that even the original demo app has the same memory allocation issue.
In addition, I noticed that if I start microphone -> stop microphone -> start microphone the allocation increased dramatically. It seems that the VOSK library doesn't clear some allocations when we stop microphone listening and create new allocations when we start the microphone listening.

The steps to reproduce the first issue:

  1. Run the VOSK Android Demo app
  2. Play any talk show on YouTube (that device can hear it and recognize the speech)
  3. Run the Android Studio Profiler (to check allocations)
  4. Leave it for 30 minutes (it will be enough to see the steady memory allocation increase)

Screenshot 2021-08-23 at 17 18 07

Screenshot 2021-08-23 at 17 18 23

Screenshot 2021-08-23 at 17 18 37

The steps to reproduce the second issue:

  1. Run the VOSK Android Demo app
  2. Play any talk show on YouTube (that device can hear it and recognize the speech)
  3. Run the Android Studio Profiler (to check allocations)
  4. Start microphone listening
  5. Wait a minute
  6. Stop microphone listening
  7. Repeat steps 4-6 several times

Screenshot 2021-08-23 at 16 41 49

Could you please clarify, is something we can do with it to solve the issue (I mean using Java code, not the c++), or is it totally on the native side and needs you to fix it?

@prechtelm
Copy link
Author

Any updates?

@dimitriosp
Copy link

Any updates @nshmyrev ?

@nshmyrev
Copy link
Collaborator

nshmyrev commented Dec 9, 2021

I didn't have time to look on this yet

@dimitriosp
Copy link

I am wondering if we are the only one with this issue?

@nshmyrev
Copy link
Collaborator

nshmyrev commented Dec 9, 2021

Depends on who are "we"

@dimitriosp
Copy link

Me and sokolyaka found the issue also on our side. Same as prechtelm.

@nanaghartey
Copy link

Faced the same issue. It seems to be an issue with how AudioRecord works or perhaps the RecognizerThread. Shutting down the speech service (speechService.shutdown()) to release the audioRecord object doesn't work. It only prevents memory allocation from increasing; it does not free up memory.
Restarting vosk will make things worse.
One workaround is to pause/resume the service(speechService.setPause(true)) intermittently, but it is not a good solution if your app needs to listen continuously without missing any input

@prechtelm
Copy link
Author

prechtelm commented Dec 28, 2021 •
edited
Loading

@nshmyrev any progress on the native lib leak?
Or did anybody find an workaround?
Memory leak is definitely traceable to vosk. Starting from Recognizer.acceptWaveForm() the RecognizerThread dumps to mem full with native code which never gets cleared. This makes the library basically unusable on Android. Is there anything we can do?

@nshmyrev nshmyrev mentioned this issue Dec 29, 2021
Closed
@dimitriosp
Copy link

Hello, any update on this issue or a proper workaround solution?
We will check if pausing the service can help here.

@nshmyrev nshmyrev changed the title Native lib crash Memory usage grows on Android, possible memory leak Jan 27, 2022
@nshmyrev nshmyrev mentioned this issue Jan 27, 2022
Closed
@sokolyaka
Copy link

sokolyaka commented Feb 15, 2022 •
edited
Loading

Faced the same issue. It seems to be an issue with how AudioRecord works or perhaps the RecognizerThread. Shutting down the speech service (speechService.shutdown()) to release the audioRecord object doesn't work. It only prevents memory allocation from increasing; it does not free up memory. Restarting vosk will make things worse. One workaround is to pause/resume the service(speechService.setPause(true)) intermittently, but it is not a good solution if your app needs to listen continuously without missing any input

Hey nanaghartey, could you please clarify your workaround? Because just pause/resume of the service doesn't work for me, and memory doesn't free up.

@DjToMeK27
Copy link

@nshmyrev hello. Do you have any update about this problem maybe?
Thanks

@nshmyrev
Copy link
Collaborator

@DjToMeK27 still looking on it. Few more days.

@DjToMeK27
Copy link

@nshmyrev hello 😅
Any news about this problem? Or is it a tricky one?

@DjToMeK27
Copy link

😢

@nshmyrev
Copy link
Collaborator

Busy days...

@prechtelm
Copy link
Author

Any news? We would love to build upon Vosk, currently not really possible...

@abouquet
Copy link

Hi @nshmyrev . Need an update on this issue please :)

@abouquet abouquet mentioned this issue Jun 13, 2023
Open
@chriskyndrid
Copy link

+1

I don't think this is isolated to the java or android sdk. I experience the same issue using the (open source) rust ffi bindings: here

@DuyenCdt
Copy link

@nshmyrev Hello. I am having the same problem. Do you have any updates on this issue?

@fanmingyi fanmingyi mentioned this issue Nov 24, 2023
Open
@timmolter
Copy link

Has anyone tried out @fanmingyi's PR solution to this memory leak issue?

@prechtelm
Copy link
Author

@timmolter can you elaborate on the exact solution?

@timmolter
Copy link

It looks like he's closing the recognizer object when setting the state to DONE.
https://github.com/alphacep/vosk-android-demo/pull/212/files

@nanaghartey
Copy link

Has anyone tried out @fanmingyi's PR solution to this memory leak issue?

I tried and the results were still the same . No improvements!

@timmolter
Copy link

Does the app eventually crash? With an OOM or what? Or does it stabilize at say 1GB or some level?

@Cvetacar
Copy link

Cvetacar commented Feb 5, 2024

We are having the same issue. Any updates on this?

@DjToMeK30
Copy link

I would say the best thing until fix comes is

  1. Run Vosk service in another process
  2. Kill and restart it after X hours

@hqweb
Copy link

hqweb commented Apr 1, 2024

大佬，解决下吧，求求了

@nichem
Copy link

nichem commented Apr 2, 2024

Any updates？ @nshmyrev

@matanel-6over6
Copy link

this is the solution:
It looks like he's closing the recognizer object:
https://github.com/alphacep/vosk-android-demo/pull/212/files

What timmolter wrote. 10x a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests