|
From: Alexander P. <gl...@go...> - 2010-08-09 14:27:01
|
Found this in coregrind/m_syswrap/syswrap-darwin.c:
=======================================
PRE(chmod_extended)
{
/* DDD: Note: this is not really correct. Handling of
fchmod_extended is broken in the same way. */
PRINT("chmod_extended ( %#lx(%s), %ld, %ld, %ld, %#lx )",
ARG1, ARG1 ? (HChar*)ARG1 : "(null)", ARG2, ARG3, ARG4, ARG5);
PRE_REG_READ5(long, "chmod",
unsigned int, fildes,
uid_t, uid,
gid_t, gid,
vki_mode_t, mode,
void* /*really,user_addr_t*/, xsecurity);
PRE_MEM_RASCIIZ("chmod_extended(path)", ARG1);
/* DDD: relative to the xnu sources (kauth_copyinfilesec), this
is just way wrong. [The trouble is with the size, which depends on a
non-trival kernel computation] */
PRE_MEM_READ( "chmod_extended(xsecurity)", ARG5,
sizeof(struct vki_kauth_filesec) );
}
=======================================
As I understand, the size of the last argument of [f]chmod_extended
may vary on 10.5. Is it still so on 10.6?
On Mon, Aug 9, 2010 at 4:13 PM, Alexander Potapenko <gl...@go...> wrote:
> Hi all,
>
> I'm getting the following reports while running some Chromium
> unittests under Memcheck on OS X 10.6:
>
> ===================================
> Syscall param fchmod_extended(xsecurity) points to unaddressable byte(s)
> __fchmod_extended
> fchmodx_np
> copyfile_internal
> copyfile
> file_util::CopyFile(FilePath const&, FilePath const&)
> (/Users/glider/src/chromium/src/base/file_util_mac.mm:30)
>
> Syscall param chmod_extended(xsecurity) points to unaddressable byte(s)
> __chmod_extended
> chmodx_np
> copyfile
> file_util::CopyFile(FilePath const&, FilePath const&)
> (/Users/glider/src/chromium/src/base/file_util_mac.mm:30)
> ===================================
>
> When I run dtruss on these tests I find out that the syscalls are
> invoked with almost no arguments:
> chmod_extended(0x1330000, 0x0, 0x0, 0x0, 0x0) and
> fchmod_extended(0x5, 0x0, 0x0, 0x0, 0x0)
> , where 0x5 is a valid file descriptor (it's used by other syscalls)
> and 0x1330000 is a valid string (ditto).
>
> I suspect the reports are caused by some harmless optimization which
> was not used in 10.5 but appeared in 10.6.
> Does anyone have any insight about this?
>
> Thanks in advance,
> Alexander Potapenko
> Software Engineer
> Google Moscow
>
--
Alexander Potapenko
Software Engineer
Google Moscow
|