List items
Items from the current list are shown below.
Blog
18 Mar 2024 : Day 189 #
The memory graphs we looked at yesterday told a different story to the one we were expecting. The memory usage didn't shoot through the roof, instead stay stable at between 200-250 MB. So if memory allocation isn't the problem, it does beg the question of what is. It could be that it's graphics related, that is, to do with the way GL and EGL textures are being created and destroyed.
Despite this I still think it may be worthwhile running the harbour-webview app through valgrind. Valgrind is a debugging tool that, amongst other tricks, will tell you the state of the memory when the application is exited. In case some portion of the allocated memory isn't freed up at the end, it will highlight the fact. It'll also tell you all sorts of other useful memory information. But crucially, if memory isn't being freed, then that's typically a sign of a memory leak.
In the case of EmbedLite the memory management is pretty flaky, making it hard to disentangle what's normal from what's exceptional. I've nevertheless collected valgrind logs from both harbour-webview and sailfish-browser. I did this on both ESR 78 and ESR 91 in the hope that performing some kind of comparison might be useful. First on my phone running ESR 78:
There are multiple mismatched frees related to QMozViewPrivate::createView(), android_dlopen(), do_dlopen(), QCoreApplicationPrivate::sendPostedEvents(), QMozSecurity, QSGNode::destroy(), QMozContext and others. These all look unrelated to the parts of the code I'm looking at, plus they also appear for both ESR 78 and ESR 91. So I'm going to leave those to one side for now. It may be that there's some useful work to be done cleaning all of these up, but I don't believe they relate to the rendering issues I'm experiencing.
There are also a collection of memory bugs that happen in the Compositor thread. These are far more likely to relate to the changes I've been looking at. There are some that reference CompositorOGL::GetShaderProgramFor(), but which appear for both ESR 78 and ESR 91. Given they're in both, I think I'll ignore those as well.
There are four further errors which I can see appear in ESR 91 but not ESR 78. These are the ones I want to focus on. The first one doesn't seem to be directly associated with the gecko code. It references EGL, so it's possible it's related, but without something more concrete I'm not sure what to do with it.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Despite this I still think it may be worthwhile running the harbour-webview app through valgrind. Valgrind is a debugging tool that, amongst other tricks, will tell you the state of the memory when the application is exited. In case some portion of the allocated memory isn't freed up at the end, it will highlight the fact. It'll also tell you all sorts of other useful memory information. But crucially, if memory isn't being freed, then that's typically a sign of a memory leak.
In the case of EmbedLite the memory management is pretty flaky, making it hard to disentangle what's normal from what's exceptional. I've nevertheless collected valgrind logs from both harbour-webview and sailfish-browser. I did this on both ESR 78 and ESR 91 in the hope that performing some kind of comparison might be useful. First on my phone running ESR 78:
$ valgrind --log-file=valgrind-harbour-webview-esr78-01.txt harbour-webview $ valgrind --log-file=valgrind-sailfish-browser-esr78-01.txt sailfish-browserAnd then following that on a different phone running ESR 91:
$ valgrind --log-file=valgrind-harbour-webview-esr91-01.txt harbour-webview $ valgrind --log-file=valgrind-sailfish-browser-esr91-01.txt sailfish-browserThe task now is to manually compare the two. The ESR 91 valgrind output shows a lot of errors:
==29044== ERROR SUMMARY: 7057 errors from 159 contexts (suppressed: 0 from 0)That's more than the number of errors in the ESR 78 output, but it's not an order of magnitude different:
==17128== ERROR SUMMARY: 5737 errors from 155 contexts (suppressed: 0 from 0)Skimming through, there are a lot of mismatched frees shown for QtWaylandClient; in fact this seems to be the majority of them. However these appear for both ESR 78 and ESR 91. I don't recommend it, but if you'd like to take a look yourself I've uploaded both the ESR 78 valgrind output and the ESR 91 valdgrind output and you're very welcome to take a look yourself. You might spot something I missed.
There are multiple mismatched frees related to QMozViewPrivate::createView(), android_dlopen(), do_dlopen(), QCoreApplicationPrivate::sendPostedEvents(), QMozSecurity, QSGNode::destroy(), QMozContext and others. These all look unrelated to the parts of the code I'm looking at, plus they also appear for both ESR 78 and ESR 91. So I'm going to leave those to one side for now. It may be that there's some useful work to be done cleaning all of these up, but I don't believe they relate to the rendering issues I'm experiencing.
There are also a collection of memory bugs that happen in the Compositor thread. These are far more likely to relate to the changes I've been looking at. There are some that reference CompositorOGL::GetShaderProgramFor(), but which appear for both ESR 78 and ESR 91. Given they're in both, I think I'll ignore those as well.
There are four further errors which I can see appear in ESR 91 but not ESR 78. These are the ones I want to focus on. The first one doesn't seem to be directly associated with the gecko code. It references EGL, so it's possible it's related, but without something more concrete I'm not sure what to do with it.
==29044== Mismatched free() / delete / delete []
==29044== at 0x484E2B8: free (vg_replace_malloc.c:872)
==29044== by 0x15CE6943: ??? (in /usr/libexec/droid-hybris/system/lib64/
libEGL.so)
==29044== by 0x15CE590B: ??? (in /usr/libexec/droid-hybris/system/lib64/
libEGL.so)
==29044== by 0x15CE523F: ??? (in /usr/libexec/droid-hybris/system/lib64/
libEGL.so)
==29044== by 0x15CDC4BF: ??? (in /usr/libexec/droid-hybris/system/lib64/
libEGL.so)
==29044== by 0x15CDC7A3: eglGetDisplay (in /usr/libexec/droid-hybris/system/
lib64/libEGL.so)
==29044== by 0xCCF63AF: ??? (in /usr/lib64/libEGL.so.1.0.0)
==29044== by 0x14960F73: ??? (in /usr/lib64/qt5/plugins/
wayland-graphics-integration-client/libwayland-egl.so)
==29044== by 0x14778947: QtWaylandClient::QWaylandIntegration::
initializeClientBufferIntegration() (in /usr/lib64/
libQt5WaylandClient.so.5.6.3)
==29044== by 0x14778C6F: QtWaylandClient::QWaylandIntegration::
clientBufferIntegration() const (in /usr/lib64/libQt5WaylandClient.so.5.6.3)
==29044== by 0x147784F3: QtWaylandClient::QWaylandIntegration::hasCapability(
QPlatformIntegration::Capability) const (in /usr/lib64/
libQt5WaylandClient.so.5.6.3)
==29044== by 0x4B3EA1F: QSGRenderLoop::instance() (in /usr/lib64/
libQt5Quick.so.5.6.3)
==29044== Address 0x14bd40c0 is 0 bytes inside a block of size 48 alloc'd
==29044== at 0x484BD54: operator new(unsigned long) (vg_replace_malloc.c:420)
==29044== by 0x15A5C167: ??? (in /usr/libexec/droid-hybris/system/lib64/
libc++.so)
Similarly, although the following is apparently happening in the Compositor thread, I don't see a way to tie it to the gecko code.
==29044== Mismatched free() / delete / delete []
==29044== at 0x484E2B8: free (vg_replace_malloc.c:872)
==29044== by 0x174836EF: ??? (in /odm/lib64/libllvm-glnext.so)
==29044== Address 0x2156db90 is 0 bytes inside a block of size 48 alloc'd
==29044== at 0x484BD54: operator new(unsigned long) (vg_replace_malloc.c:420)
==29044== by 0x163E9167: std::__1::basic_string<char, std::__1::
char_traits<char>, std::__1::allocator<char> >::__grow_by_and_replace(
unsigned long, unsigned long, unsigned long, unsigned long, unsigned long,
unsigned long, char const*) (in /apex/com.android.vndk.v30/lib64/libc++.so)
==29044== by 0x163E9273: std::__1::basic_string<char, std::__1::
char_traits<char>, std::__1::allocator<char> >::append(char const*) (in /
apex/com.android.vndk.v30/lib64/libc++.so)
==29044== by 0x17483623: ??? (in /odm/lib64/libllvm-glnext.so)
That leaves two remaining issues, both occurring in the Compositor thread. These look like the most promising avenues to look into, but I'm not going to look at them today; they'll need a bit more time than I have right now. I'll give full details and start working through them tomorrow.If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments