dr_module_contains_addr fails for a function address

[Mohammad Ewais]

I am intercepting pthread_create calls in an application by using drwrap_wrap

In the pre function wrapper. I investigate the arguments of the pthread_create call using drwrap_get_arg. I am specifically having an issue with argument #2 (0-based) which is the function pointer that gets run by the pthread_create call.

Since the function being called is a global function in a program, I was expecting this to be part of the main module. However, testing this argument with dr_module_contains_addr actually fails, indicating that this is NOT part of the module!

just to be extra sure, I get the main module using dr_get_main_module and here's the simple test program I am using:

#include <iostream>

#include <pthread.h>

void* foo(void* data)

{

    std::cout << "FOO CALLED\n";

    return nullptr;

}

void* bar(void* x)

{

    int32_t val = *(int32_t*)x;

    std::cout << "BAR CALLED WITH " << val << "\n";

    return nullptr;

}

int main(int argc, char** argv)

{

    pthread_t all_threads[16];

    uint32_t all_data[15];

    pthread_create(&all_threads[0], nullptr, &foo, nullptr);

    for (uint32_t i = 1; i < 16; i++)

    {

        all_data[i-1] = i;

        pthread_create(&all_threads[i], nullptr, &bar, &all_data[i-1]);

    }

    for (uint32_t i = 0; i < 16; i++)

    {

        pthread_join(all_threads[i], nullptr);

    }

    return 0;

}

I have also managed to verify the NULL arguments of the pthread_call, I have also verified that the other operands do exist on the stack (which is correct for the way I coded the test program). And when I changed the arrays in the program to std::vectors, I was able to detect that these operands were no longer on the stack, again, as expected. So the only thing out of the ordinary is just operand #2, the function pointer. Any plausible explanations?

[Derek Bruening]

What is the value of that argument and where in /proc/self/maps does it fit?  Is it in the executable, and you're saying DR's bounds for the executable segments are incorrect (and if so, what are the maps entries for the executable, and what does DR have recorded)?  Or you're saying DR has the executable segment bounds right and this argument value from drwrap is not the right value b/c it has the wrong calling convention or sthg?

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/12835d79-1143-4146-a26d-de0f74983dcen%40googlegroups.com.

[Mohammad Ewais]

I am terribly sorry, I have made a very stupid mistake.

Apparently, I was somehow running an older version of the test program which lingered on my test server, rather than the development machine. That older version was using C++ std::thread instead of pthread_create. This was causing the issue I was facing. Converting this to use pthread instead matched the expected behavior.

Terribly sorry.