Mali Graphics Debugger : libGLES_mgd.so makes crash application

Hello Chris,

Sorry for my late response and thank you for helping me with my problem.

Here are the info you asked for :

root@android:/system/lib/egl # ll

-rw-r--r-- root     root            8 2014-02-20 10:34 egl.cfg

-rw-r--r-- root     root          416 2014-02-12 14:56 egl.cfg.bak

-rw-r--r-- root     root        83196 2014-02-12 16:53 libEGL_android.so

-rw-r--r-- root     root        13328 2013-10-10 05:24 libEGL_mali.so

-rw-r--r-- root     root        83196 2013-10-10 05:24 libGLES_android.so

-rwxrwxrwx root     root       272120 2014-02-20 10:34 libGLES_mgd.so

-rw-r--r-- root     root        25624 2013-10-10 05:24 libGLESv1_CM_mali.so

-rw-r--r-- root     root        21524 2013-10-10 05:24 libGLESv2_mali.so

-rw-rw-rw- root     root           18 2014-02-12 15:37 processlist.cfg

root@android:/system/vendor/lib # ll /vendor/lib

ll /vendor/lib

drwxr-xr-x root     shell             2014-02-12 14:09 drm

drwxr-xr-x root     shell             2014-02-12 14:09 hw

-rw-r--r-- root     root       420936 2013-10-10 05:24 liblvverx_3.18.03.so

-rw-r--r-- root     root       441536 2013-10-10 05:24 liblvvetx_3.18.03.so

-rw-r--r-- root     root        62708 2013-10-10 05:24 libwvm.so

root@android:/system/vendor/lib # ll /system/vendor/lib

ll /system/vendor/lib

drwxr-xr-x root     shell             2014-02-12 14:09 drm

drwxr-xr-x root     shell             2014-02-12 14:09 hw

-rw-r--r-- root     root       420936 2013-10-10 05:24 liblvverx_3.18.03.so

-rw-r--r-- root     root       441536 2013-10-10 05:24 liblvvetx_3.18.03.so

-rw-r--r-- root     root        62708 2013-10-10 05:24 libwvm.so

root@android:/system/vendor/lib #

And the logcat are in attachment. I made two logs : one with the library named libGLES_mgd.so as you asked. And another with the library name libEGL_mgd.so.

For both I just tried to launch the web browser. But all apps crash like that.

I hope you'll find a solution!

Thank you anyway!

Hi ybe42,

Ok, interesting one to debug.

First off, renaming to libEGL_mgd.so is not advised. Due to the way Android loads graphics libraries, it will first look for the monolithic "libGLES_tag.so" file, and failing that will look for separate libraries. So, it will look for libEGL_mgd.so and find it, but fail to find libGLESv2_mgd.so. Not sure what the behaviour would be in this case, but if it worked at all it would result in only EGL being traced by MGD. This isn't what you want. You say you manage to get a frame trace out of it, but in this log you only get as far as eglMakeCurrent? For what it's worth Chrome browser is not a good test case to get this working as it does crazy things with multiple threads which we don't fully support at present, I'd recommend something relatively simple like the settings app or our Spinning Cube SDK example, for sanity checking.

The libGLES_mgd.so method is the correct one, and in this log I'm not seeing any output from mgd_interceptor at all, just "E/libEGL  ( 5818): eglGetDisplay:121 error 300c (EGL_BAD_PARAMETER)" which past experience is leading me towards this being a permissions issue. Are you sure that the permissions were 777 on both libGLES_mgd.so and processlist.cfg? Does it work if you remove processlist.cfg?

I'll see if we have one of these devices lying around and I'll try and reproduce your problem.

Thanks,

Chris

Chris Varnsverry a écrit:

Hi ybe42,

Ok, interesting one to debug.

First off, renaming to libEGL_mgd.so is not advised. Due to the way Android loads graphics libraries, it will first look for the monolithic "libGLES_tag.so" file, and failing that will look for separate libraries. So, it will look for libEGL_mgd.so and find it, but fail to find libGLESv2_mgd.so. Not sure what the behaviour would be in this case, but if it worked at all it would result in only EGL being traced by MGD. This isn't what you want. You say you manage to get a frame trace out of it, but in this log you only get as far as eglMakeCurrent? For what it's worth Chrome browser is not a good test case to get this working as it does crazy things with multiple threads which we don't fully support at present, I'd recommend something relatively simple like the settings app or our Spinning Cube SDK example, for sanity checking.

The libGLES_mgd.so method is the correct one, and in this log I'm not seeing any output from mgd_interceptor at all, just "E/libEGL  ( 5818): eglGetDisplay:121 error 300c (EGL_BAD_PARAMETER)" which past experience is leading me towards this being a permissions issue. Are you sure that the permissions were 777 on both libGLES_mgd.so and processlist.cfg? Does it work if you remove processlist.cfg?

I'll see if we have one of these devices lying around and I'll try and reproduce your problem.

Thanks,

Chris

Hi,

I did the test with the setting apps, and the result is pretty much the same, with same error messages : "E/libEGL  ( 5818): eglGetDisplay:121 error 300c (EGL_BAD_PARAMETER)". I checked permission on libGLES_mgd.so and it is 777 (you can see it in my previous message btw). I tried to change processlist.cfg to 777, and also to remove it as you suggested, but it didn't work.

The reason why I renamed libGLES_mgd.so to libEGL_mgd.so is that it gave me more relevant error messages. At least I saw the interceptor in the logcat and received a few command on the mgd on my host (the file I attached in my first post). But if you say to me it's not the solution, I stop digging in that direction.

Thank you for your help, I am ready to test whatever suggestion you could have!

Ybe

Hi,

So I did what you suggest and I actually still got interceptor calls in the logcat. I put it in attachment so you can analyse it.

As you told me, the app is still not starting. But it doesn't crash this time! I just got a white screen with no icons and text.

It seems that we are progressing! I am looking forward to hear your next instruction!

Thank you for your help!

Ybe

Hi,

The log is for the settings app, are you saying the settings app is not displaying, only white?

Also if you connect the host, do you get trace logging?

Thanks,

Chris

Hi,

Yes the logcat is for the app Settings, I just got a white screen when I try to launch it. It's the same with all other apps. They don't crash but they don't draw anything either.

I get some trace on the host, I've put them in attachment.

Thank you,

Ybe

Ok so the story so far is:

In the symbolicLink.txt file we can see these 2 lines:

     D/libEGL  (27973): loaded /system/lib/egl/libEGL_mgd.so

     D/libEGL  (27973): loaded /system/lib/egl/libGLESv2_mgd.so

so Android EGL is managing to find MGD when looking for libEGL and libGLESv2, good stuff. I can also see in the output that MGD attempts to and succeeds in opening libEGL_mali.so. This is triggered on the first call to an egl function, and from the AppSettingTrace file I can see a whole bunch of eglGetProcAddress calls which is the Android EGL layer making calls to the library to get common extensions. Good stuff, Android can call into the real libs through MGD and MGD is tracing these.

I see no other activity for EGL or GLES, which implies that the application is making no other calls to either EGL or GLES through the Android EGL layer. This seems a bit weird.

Are you sure they're symlinks and havent ended up being copied as 2 separate libraries to the directory? Can you make a symlink from libGLES_mgd.so to mgd.so and send me logcat and mgd trace for that? Having EGL load libGLES_*.so is the ideal way and the way MGD expects to be loaded, so we might be hitting a strange bug by not doing this. The fact that it seems to be creating a different socket to the daemon for EGL and GLES at present is ringing alarm bells for me, so I'll double check that.

Hopefully we can get this working

Thanks,

Chris

Hello Chris!

I checked if symlinks was good and they seems ok to me. I've put screenshots in attachment so you can check it.

I tried what you've suggested by adding a symlink for libGLES_mgd.so. But it results in no changes in the behaviour of the application.

You will find in attachment the logcat and the mgd trace.

Thank you!

Ybe42

Edit : Interesting fact! With the same configuration (same symlinks and egl.cfg), if I disable mgddaemon and close mgd on the host, the application managed to be launched. I've added the logcat in attachment (logcat-24-02-2014 - No mgddaemon.txt).

Hmm.. in the log without mgddaemon running, MGD appears to load libEGL_mali.so from /system/lib/egl, and libGLESv2_mali.so from /vendor/lib/egl. Can you confirm this is the case? Was it like this from stock or did you copy some things around?

That still doesn't explain why it works without the daemon running however... But, here's what I have so far:

1. Your version of Android doesn't appear to be attempting to load a monolithic library (libGLES_*.so) at all. It seems to only look for the non-monolithic libraries, libEGL, libGLESv2, and libGLESv1_CM. This explains why you got further when you renamed it to libEGL.so, and is likely the root cause of the problem. If you look at the Android source code, it always looks for the monolithic library first, but it looks like this path has been removed in your Android build.
2. Symlinking libEGL and libGLESv2 to mgd.so fixes the above, and this works as long as the daemon is not running (i.e. passing straight through, no attempt to trace).
3. With the mgddaemon running, the application seems to fall over before any GLES activity occurs, because in the log we never see any "Attempting to load libGLESv2" or similar from mgd_interceptor. The load should happen on the first call to a GLES API function. We do see activity for libEGL and get trace for that in the host when it is connected.
   
4. When symlinking the non-monolithic libraries to mgd.so, there are 2 connections made from the interceptor to the daemon, one for each library.

This all seems to stem from your platform not looking for a monolithic library at all, but debate is ongoing internally I notice that the mali driver does not use symlinks, and instead has proper shims, so we will probably have to do the same and provide some non-monolithic shims to solve this problem. This week is MWC and I don't have a Tab3 to test on at present, but we'll get this on the backlog and it should be fixed in a future release. For now unfortunately I don't think it will work on a system that does not load monolithic libraries.

EDIT: Assuming you can build Android for this device, doing so might be an option, it would result in the standard Android EGL loading mechanism.

Thanks,

Chris

Hmm.. in the log without mgddaemon running, MGD appears to load libEGL_mali.so from /system/lib/egl, and libGLESv2_mali.so from /vendor/lib/egl. Can you confirm this is the case? Was it like this from stock or did you copy some things around?

Strangely, no. I don't see any libGLESv2_mali.so in the vendor directory. I don't know how it can find it there. In attachment, the list of files in the vendor/lib directory.

Well, I understand your explanation on libraries loading. It is weird that I am the first facing this problem, isn't it? Maybe Samsung has just change their kernel recently...(The tab was bought just a month ago)?

So I'll wait till your next release hopping it will be fixed !

In any case, thank you very much for your help and explanations! Don't hesitate to contact me if you have any new information on this problem or if you want me to test some procedure on the galaxy tab.

Bye,

Ybe42

It is interesting that you got further with that rename, but it will cause other problems down the line i.e. you wont be tracing any GLES calls . Hmm.... Ok then, if renaming to libEGL_mgd.so works maybe we can try the following:

     adb shell su

     mount -o remount /system

     mv /system/lib/egl/libGLES_mgd.so /system/lib/egl/mgd.so

     ln -s /system/lib/egl/mgd.so /system/lib/egl/libEGL_mgd.so

     ln -s /system/lib/egl/mgd.so /system/lib/egl/libGLESv2_mgd.so

I'm thinking if you get further with calling it libEGL_mgd.so, then it's worth testing if it can also do it if libEGL_mgd.so is actually a symlink to mgd.so. If that works, then at least it will also work for GLES and you will get all the API calls for both. That solves one problem.

Let me know if that still results in some output from the interceptor on logcat? It will probably still crash but one step at a time.

Bit of an update, the core issue here is that recent ROMs for certain Samsung devices remove the ability to load monolithic libraries, and they instead only look for the fragmented libEGL_mgd, libGLESv2_mgd, and libGLESv1_CM_mgd libraries. The solution therefore is to create symlinks from these to libGLES_mgd and the problem should be solved. There are some separate issues on the Tab3 apparently but this has worked fine on everything else I've tested it on, so let us know if you hit troubles. These steps will be included in the user guide going forward also, so if you're getting here from google be sure to check that for up-to-date instructions and troubleshooting.