Why is my mprotect function called with 5 arguments?

Question

According to the Linux man page for mprotect the function has 3 arguments:

int mprotect(const void *addr, size_t len, int prot);

but while running ltrace on a program that I'm analyzing I see that mprotect is called like this:

mprotect(0x8049000, 4096, 3, 1, 0xb7e057ac)      = 0

What are the 4th and 5th arguments for?

I'm using ltrace version 0.5. and kernel 2.6.24-24-generic

Infamy

How about the fifth one? – Heller

sorry, while scanning the arguments I missed the 4th one ;) – Infamy

Which version of strace. Which version of the linux kernel? – Betweenwhiles

Sorry, see now that you said ltrace. – Betweenwhiles

@marco, print out the values of the addr, len and prot parametrs – Jewell

ltrace is just getting these items off of the call stack. the real question is why are they getting pushed on there in the first place. – Hearsay

Answer 1

Five is the number of arguments that ltrace will print if it can not find the description of the function in the config file. (/etc/ltrace.conf by default, I think).

On my system I can see the same behaviour, and the mprotect is not found there, only the SYS_mprotect.

If you want to have a second look of the ltrace source, the place of interest is the output.c, the conditional after "func = name2func(function_name);" - which prints 5 args in case the meta-info for the function name is not found (and in which case the linear lookup within the name2func returns NULL).

So, the manual is correct, it's ltrace which is "wrong" (quoted "wrong" because technically the code works as it should, though probably the defs in the config should be fixed)

Flinch

These days it seems to be ret->num_params = 4; in build_default_prototype. Thanks for this comment, though, it helped me find out how ltrace determines # args from an unknown function. I hoped it would be some magic algorithm. – Punkie