|
From: Alexander P. <gl...@go...> - 2010-08-09 12:13:34
|
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 |
|
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
|
|
From: Julian S. <js...@ac...> - 2010-08-12 08:59:53
|
> > Does anyone have any insight about this?
Not me. Do you have a potential patch? Is this being tracked on the
bug tracker?
J
On Monday, August 09, 2010, Alexander Potapenko wrote:
> 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
|
|
From: Alexander P. <gl...@go...> - 2010-08-12 11:59:34
|
On Thu, Aug 12, 2010 at 1:03 PM, Julian Seward <js...@ac...> wrote: > >> > Does anyone have any insight about this? > > Not me. Do you have a potential patch? Not yet > Is this being tracked on the > bug tracker? It now is, see https://bugs.kde.org/show_bug.cgi?id=247510 > > J > > On Monday, August 09, 2010, Alexander Potapenko wrote: >> 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 |