← Back to team overview

ubuntu-phone team mailing list archive

Re: Android ATOMIC problems

 

Hi, Petr.

On Mon, Apr 29, 2013 at 2:53 PM, Petr Bláha <pb@xxxxxxxx> wrote:
>
> Hi Alex,
>
> thank you for your reply and for your time you have spent with my problem.
>
> extern inline int32_t android_atomic_add(int32_t increment, volatile int32_t *ptr)
> {
>     int32_t prev, tmp, status;
>     android_memory_barrier();
>     do {
>         __asm__ __volatile__ ("ldrex %0, [%4]\n"
>                               "add %1, %0, %5\n"
>                               "strex %2, %1, [%4]"
>                               : "=&r" (prev), "=&r" (tmp),
>                                 "=&r" (status), "+m" (*ptr)
>                               : "r" (ptr), "Ir" (increment)
>                               : "cc");
>     } while (__builtin_expect(status != 0, 0));
>     return prev;
> }
>
> Maybe this is a goog point to add some debug code.
Maybe.

> I expect that %0 stands for 1st, %1 for 2nd parameter and so, or I am wrong?
%0 stands for prev, %1 stands for tmp, %2 stands for status, %4 stands
for ptr and %5 stands for increment.

> In that case will first line of assembler code be ldrex r0, [r4] ...
r0 and r4 are picked up by a compiler and could be any from a valid
ARM set, like ldrex r3, [r5]. They do not correlate with %0, %4.
Numbers are just coincidence.
More info could be found in the "GCC Inline Assembly HOWTO".

> I need to investigate how to add some debug function here. But this will not explain where from this get bad pointer.
Well, I am not sure you have to do all this. But if you are serious, I
suggest to add a backtrace to android_atomic_add.
When the ptr parameter looks wrong, android_atomic_add will log a backtrace.
Something about the following (pseudo-code):
extern inline int32_t android_atomic_add(int32_t increment, volatile
int32_t *ptr)
{
    if (ptr < "minimum valid section address")
    {
        backtrace();  // your function
    }
...
}

An example of how to do backtracing:
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/F1q_qw5MFfU
I don't know, but maybe Android already has similar functionality
build-in, and you don't have to write your backtrace().


> I am glad you can confirm that problematic part is ubuntuappmanager. I have written few emails to this  mailinglist about my problems with this part of code, but you are very first that can confirm my hypothesis.
It's not that I'm sure, rather ubuntuappmanager looks very suspicious.

> Regards Petr

Cheers.


References