search for: 12777299

On 30 November 2012 13:32, Alexander Potapenko <glider at google.com> wrote: > No, we are not going to use mach_inject. This isn't portable and may > be even harder to set up than mach_override. > The new ASan runtime will use the dylib interposition and will in fact > require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > correctly itself: if the

...t;> --kcc >> >> >> On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >> wrote: >>> >>> Nick, >>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>> I uploaded into the newly opened radr://12777299, "potential >>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>> have ported llvm.org's asan code into FSF gcc (and are keeping >>> it synced to the upstream llvm.org code). I have been helping >>> with the darwin build and testin...

On Tue, Dec 04, 2012 at 09:46:09AM -0800, Alexander Potapenko wrote: > +kledzik at apple.com > The dynamic runtime is using dylib interposition (google for > "__DATA,__interpose). > If I'm understanding correctly (Nick, can you please confirm this?) > this allows to interpose the function regardless of the two-level > namespace. > The support for dynamic runtime in

Nick, Can you take a quick look at the asan_eh_bug.tar.bz testcase I uploaded into the newly opened radr://12777299, "potential pthread/eh bug exposed by libsanitizer". The FSF gcc developers have ported llvm.org's asan code into FSF gcc (and are keeping it synced to the upstream llvm.org code). I have been helping with the darwin build and testing -fsanitize=address against the complete FSF gcc t...

...ould expect the same failures with clang. Alex, could you please take a look? --kcc On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Can you take a quick look at the asan_eh_bug.tar.bz testcase > I uploaded into the newly opened radr://12777299, "potential > pthread/eh bug exposed by libsanitizer". The FSF gcc developers > have ported llvm.org's asan code into FSF gcc (and are keeping > it synced to the upstream llvm.org code). I have been helping > with the darwin build and testing -fsanitize=address against the...

...howarth at bromo.med.uc.edu> >> > >>> wrote: >> > >>>> >> > >>>> Nick, >> > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >> > >>>> I uploaded into the newly opened radr://12777299, "potential >> > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >> > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping >> > >>>> it synced to the upstream llvm.org code). I have been...

...AM, Alexander Potapenko wrote: >> On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >> wrote: >>> >>> Nick, >>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>> I uploaded into the newly opened radr://12777299, "potential >>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>> have ported llvm.org's asan code into FSF gcc (and are keeping >>> it synced to the upstream llvm.org code). I have been helping >>> with the darwin build and testin...

+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some issues with the allocator which

...ould you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> > wrote: >> >> Nick, >> Can you take a quick look at the asan_eh_bug.tar.bz testcase >> I uploaded into the newly opened radr://12777299, "potential >> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >> have ported llvm.org's asan code into FSF gcc (and are keeping >> it synced to the upstream llvm.org code). I have been helping >> with the darwin build and testing -fsanitize=add...

...warth < > > howarth at bromo.med.uc.edu> > > >>> wrote: > > >>>> > > >>>> Nick, > > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > > >>>> I uploaded into the newly opened radr://12777299, "potential > > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > > >>>> it synced to the upstream llvm.org code). I have been helping &gt...

...wrote: >>> On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >>> wrote: >>>> >>>> Nick, >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>>> I uploaded into the newly opened radr://12777299, "potential >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>>> have ported llvm.org's asan code into FSF gcc (and are keeping >>>> it synced to the upstream llvm.org code). I have been helping >>>> with the darwin...

...t; > > > > >>> wrote: > > > > >>>> > > > > >>>> Nick, > > > > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > > > > >>>> I uploaded into the newly opened radr://12777299, "potential > > > > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > > > > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > > > > >>>> it synced to the upstream llvm.org...

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start

...v 29, 2012 at 9:55 PM, Jack Howarth < > howarth at bromo.med.uc.edu> > >>> wrote: > >>>> > >>>> Nick, > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > >>>> I uploaded into the newly opened radr://12777299, "potential > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > >>>> it synced to the upstream llvm.org code). I have been helping > >>>&...

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

...rth at bromo.med.uc.edu> > > > >>> wrote: > > > >>>> > > > >>>> Nick, > > > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > > > >>>> I uploaded into the newly opened radr://12777299, "potential > > > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > > > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > > > >>>> it synced to the upstream llvm.org code). I have b...

...warth < > > howarth at bromo.med.uc.edu> > > >>> wrote: > > >>>> > > >>>> Nick, > > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > > >>>> I uploaded into the newly opened radr://12777299, "potential > > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > > >>>> it synced to the upstream llvm.org code). I have been helping &gt...