You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi we have a service that runs AddressExpander java binding. The pods get restarted due to OOM once in a while and we did some analysis on possible memory leak. It turns out that there might be memory leak in expand_alternative_phrase_option function, as shown in the jemalloc analysis output here
Any idea how we can solve this issue?
The text was updated successfully, but these errors were encountered:
Ran some expander tests under valgrind, and am not seeing any memory leaks on the C side. The code complexity in expand_address is greater than I'd prefer, so depending on the input (language, script, transliteration) there are a number of different paths it can take. Not seeing anything immediately apparent in expand_alternative_phrase_option but would need a reproducible test case.
It's best if you can reduce the problem to a single input. In order to conclude whether there's a leak in libpostal itself vs. somewhere else, it should be possible to run (without Java, just use the native cli program that builds as part of libpostal after running make), valgrind --leak-check=full ./src/libpostal "YOUR ADDRESS GOES HERE" and see a memory leak that way. If you can find an address where that's true, post it here. Otherwise, it might be in the JNI binding (in that case again, see if you can make a reproducible cli-based Java program which can demonstrate the leak).
Hi we have a service that runs AddressExpander java binding. The pods get restarted due to OOM once in a while and we did some analysis on possible memory leak. It turns out that there might be memory leak in
expand_alternative_phrase_option
function, as shown in the jemalloc analysis output hereAny idea how we can solve this issue?
The text was updated successfully, but these errors were encountered: