Android OS Forum banner
1 - 12 of 12 Posts

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #1 ·
Hey everyone! Maybe you know me, and maybe you don't, but I'm a developer (just like you) here at RootzWiki. I develop just one ROM for the Verizon Galaxy Nexus (toro). The ROM has taken on the name "Shiny", but it's really just a stock, AOSP build. Anyway, things have been going real well for the ROM, but I just recently noticed a pretty big problem that I can't seem to find the source of no matter what I try. The problem has to do with the Google Play Movies & TV app. When attempting to play a purchased video in the app, it seems to be buffering like normal but eventually displays the generic error, "There was a problem while playing. Touch to retry." It's definitely something I would like to get working, but I'm having a tough time finding the source of the issue.

I have obtained a pretty good logcat of when the problem occurs, and trimmed it down to the most important part. Check it out here: http://pastebin.com/s3LNAiF3 (the actual error begins around line 48)

I also made sure to take a kernel log (via kmsg) which you can view here: http://pastebin.com/T8bNKQtd (in this one, the error begins around line 70)

Any help or advice on this issue would be appreciated a lot. Please let me know if you have any ideas, or if you would like to see any additional information. Thanks in advance to anyone who reads this or takes the time to respond!
 

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #3 ·
That app is closed source and not part of AOSP.
Right, but the problem isn't coming from within the app. The app works just fine on other builds, and even more strange it's working with some custom kernels, but not the stock, AOSP one. Also, the same exact app worked perfectly prior to 4.2. Therefore, it has to be something configured incorrectly in the 4.2 GNex source. Basically what I need help with is shedding light on the actual source of the error, which probably is not the Google Play Movies & TV app.
 

·
Premium Member
Joined
·
4,348 Posts
It's a segmentation fault. Means the app was trying to access memory that didn't exist (or did exist and no longer does) or memory it does not have access to.

The SEGV_MAPPER points to it probably being the second issue (no longer exists). Memory was probably deallowicated/corrupted and it tried to access that memory once again afterwards. Problem points to mediaserver (at line 53).

Code:
01-01 22:04:15.007: I/DEBUG(124): pid: 17118, tid: 17606, name: TimedEventQueue  >>> /system/bin/mediaserver <<<
And the problems started with: #00 pc 0001a772 /system/lib/libc.so

It's happening on the level outside of Java so it's a big mess with threading going on. Probably multiple threads accessing the same memory and one trying to access after it was freed already. If that's the case, something needs to be synchronized before it happens. Threading is all messy though and not something trivial to fix. If you really want to fix it, probably need to start debugging before it happens with gdb.

Random references:

http://en.wikipedia.org/wiki/Dangling_pointer

http://www.kandroid.org/online-pdk/guide/debugging_gdb.html

Also your issue is common (but each exact solution is obviously different), lots of references if you google the errors.
 

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #5 ·
It's a segmentation fault. Means the app was trying to access memory that didn't exist (or did exist and no longer does) or memory it does not have access to.

The SEGV_MAPPER points to it probably being the second issue (no longer exists). Memory was probably deallowicated/corrupted and it tried to access that memory once again afterwards. Problem points to mediaserver (at line...
..Also your issue is common (but each exact solution is obviously different), lots of references if you google the errors.
Hmmm okay, thanks very much! I have googled different parts of the log a few times, and did see a few things about memory faults like you just stated. I didn't really know how to go about debugging it, however, and now you've given me somewhere to start. Thank you!

One other thing I'm curious about, though, is why do you think this is happening with the stock kernel but not custom kernels? Is libc changed in any way depending on the kernel? Or do some kernels have additional measures to make sure memory allocation goes smoothly?
 

·
Premium Member
Joined
·
4,348 Posts
One other thing I'm curious about, though, is why do you think this is happening with the stock kernel but not custom kernels? Is libc changed in any way depending on the kernel? Or do some kernels have additional measures to make sure memory allocation goes smoothly?
Libc (known as Bionic on Android) is actually not part of the kernel when it's Android. It's separate since Google wanted to ensure it was not caught up in GPL issues for third party developers (so they rolled their own with bionic and licensed it under BSD). I really can't say for sure why other kernels wouldn't have the issue, I don't really follow third party kernel development on Android that much or use them. It wouldn't be something in libc though.

Libc does interact with things within the kernel though of course . Only way to really trace down the problem is just debug with gdb. There's a good visual gdb debugger for visual studio that works with Android. It's not free, but it has a 30 day trial. Just google for visual gdb.

If you start debugging and give me some more output and info, I can help more, but that's about all I can say for now.

EDIT: you would have to give me examples of whatever kernels you are saying work and provide links to the source if you wish me to look at them at some time. You could always do a diff on the kernels as well with stock and then look for commits that affected those changes and see if anything looks interesting. Kernels for Nexus devices are not all that different for the most part so changes that are likely to affected things for this issue are narrow.
 

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #7 ·
Libc (known as Bionic on Android) is actually not part of the kernel when it's Android. It's separate since Google wanted to ensure it was not caught up in GPL issues for third party developers (so they rolled their own with bionic and licensed it under BSD). I really can't say for sure why other kernels wouldn't have the issue, I don't really follow third party kernel development on Android that much or use them. It wouldn't be something in libc though.
...
EDIT: you would have to give me examples of whatever kernels you are saying work and provide links to the source if you wish me to look at them at some time. You could always do a diff on the kernels as well with stock and then look for commits that affected those changes and see if anything looks interesting. Kernels for Nexus devices are not all that different for the most part so changes that are likely to affected things for this issue are narrow.
Hey there! Thanks again for all of the great info you've given to me. I apologize for taking so long to reply; I've been balancing school with my development, but nonetheless I have been debugging this issue since you've given me the above information. Admittedly, I have zero experience with using GDB to debug, and I am having some obstacles. I can get GDB to run just fine and attach to both the Google Play Movies & TV app and the mediaserver executable. However, once I get them attached, I'm not sure exactly which direction I should go. I know that GDB has a lot of commands related to stack tracing and things like that, but what would be my best plan of action once I get these processes attached?

Also, one kernel that I have confirmed to be working with my ROM and Google Play Movies & TV is Franco's kernel (his tuna kernel for 4.2). If you want to check out his source at all, you can find it here: https://github.com/franciscofranco/Tuna_JB_pre1/tree/fk_4.2 (all credit goes to Francisco Franco of course). I still haven't had a chance to upload my source, but my kernel is 100% stock AOSP tuna kernel, no changes or modifications. I'm not sure exactly what to look for when comparing, but I've still been attempting to figure it out per your instructions.

I'm going to keep working at it, and will update you if I find anything new. If you have the time to check anything out and get an idea, please let me know! I hope this whole thread isn't making me seem desperate, but these are just some things I don't have a lot of experience on but would definitely like to learn about. I've always been good on the code side of things (Java, C, C++, etc.), but I'm not extremely familiar with some of the debugging methods like GDB, and I would definitely like to become familiar with them. Thank you again for all of your help, I appreciate it greatly!
 

·
Premium Member
Joined
·
4,348 Posts
Mostly just want to see where exactly the the error is happening in the source code for the kernel is all gdb is meant for. You would just set various breakpoints and variable values with gdb until something happens (or doesnt). I know that's sort of generic to say, though lol.

Mostly I just meant to run a diff and compare a kernel that works with one that does not and then find the commits (by looking through the git log of the kernels that work) that were related to areas that are where your crash is happening (by using the stack trace info you had with pastebin and also in tandem with using gdb). With that you can isolate where the issue is happening and find the appropriate fix needed. Then if you feel like it, attempt to commit it to AOSP (chances of them caring are slim to none though, lol).

I don't have time currently to mess with all of that myself (flashing kernels [not a fan of most non-stock kernels]) or ROMs, but that is what I would do if you want to debug around with gdb. Also don't want to pay for a google movie I won't watch or use the app really either :)

If I can help you with questions that are more explicit and finite, then let me know and I can see what I can come up with.

If it's only been an issue since 4.2, then that narrows down commits you would have to look at significantly (that plus you only need to look at non-aosp commits since obviously none of the aosp ones fixed it). If I do have some time, I'll look through the git logs though, but they're easier to read offline so I would have to pull his kernel and look around. If you're not in a hurry, then sometime later this month perhaps I can.
 

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #9 ·
Mostly just want to see where exactly the the error is happening in the source code for the kernel is all gdb is meant for. You would just set various breakpoints and variable values with gdb until something happens (or doesnt). I know that's sort of generic to say, though lol.

Mostly I just meant to run a diff and compare a kernel that works with one that does not and then find the commits (by looking through the git log of the kernels that work) that were related to areas that are where your crash is happening (by using the stack trace info you had with pastebin and also in tandem with using gdb). With that you can isolate where the issue is happening and find the appropriate fix needed. Then if you feel like it, attempt to commit it to AOSP (chances of them caring are slim to none though, lol).

I don't have time currently to mess with all of that myself (flashing kernels [not a fan of most non-stock kernels]) or ROMs, but that is what I would do if you want to debug around with gdb. Also don't want to pay for a google movie I won't watch or use the app really either :)

If I can help you with questions that are more explicit and finite, then let me know and I can see what I can come up with.

If it's only been an issue since 4.2, then that narrows down commits you would have to look at significantly (that plus you only need to look at non-aosp commits since obviously none of the aosp ones fixed it). If I do have some time, I'll look through the git logs though, but they're easier to read offline so I would have to pull his kernel and look around. If you're not in a hurry, then sometime later this month perhaps I can.
Hmmmm well I did go through some of these steps and didn't find much specific info, but I didn't take a ton of time to narrow it down either. HOWEVER, I "redid" my source tree and completely updated my whole proprietary file setup, and now Google Play Movies & TV works! It must have been an incorrect or corrupt lib or hardware driver causing the problem. Either way, the kernel issue is still a little confusing so I'll probably look into it more.

Nonetheless, thanks so much for all of your help! I'm glad I came here to learn about some helpful debugging methods that I had never known about before. It was awesome to be able to learn even a little bit from someone with so much expertise! Thanks again! If you ever want to see how the ROM is doing, check out the link in my signature


Oh and feel free to close the thread if you want since everything seems to be officially resolved :)
 

·
Shiny ROM
Joined
·
1,356 Posts
Discussion Starter · #12 ·
Thought I would pass this along when I saw it today: http://vilimpoc.org/...le-for-android/
Oh wow this is awesome! It's much more in depth and inclusive than some of the other guides I found. Even though I don't have much need for GDB at the moment I'm still going to try it out to get more experience with it. Thank you!
 
1 - 12 of 12 Posts
Top