Re: [Valgrind-developers] *chmod_extended syscall points to unaddressable bytes on OS X 10.6

[Alexander P. <gl...@go...>]

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