|
From: Nikolas Z. <zim...@kd...> - 2012-07-13 11:23:23
|
Good evening valgrind crowd, I'm a happy valgrind user for years, and even on Mac since a while. I've used it to debug WebKit with a build from around mid-March 2012 (valgrind-3.8 trunk) w/o problems. I've updated to latest ToT and it no longer works. Basically I'm facing the same issues as described in http://www.mail-archive.com/val...@li.../msg03549.html, except that I can't get the "sudo" trick working for anything but TextEdit. As I knew it worked some months ago I did some bi-sect builds: r12734 - FAILS (vex trunk): ToT r12653 - FAILS (vex trunk) r12630 - FAILS (vex trunk) r12620 - FAILS (vex trunk) ... r12458 - WORKS (vex 2267) Narrowing this even more: r12500 - FAILS (vex 2277) r12487 - FAILS (vex 2274) r12483 - FAILS (vex 2272) r12476 - FAILS (vex 2270) r12466 - FAILS (vex 2269) ~~~~~~~~~~~~~~~~~~~~~ r12465 - WORKS (vex 2269) r12464 - WORKS (vex 2269) r12460 - WORKS (vex 2269) r12459 - WORKS (vex 2268) r12458 - WORKS (vex 2267) So it's precisely commit r12466 which makes valgrind fail on at least Lion. Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad I hope this helps to fix the regression so that valgrind is usable again for us Mac ppl :-) Thanks in advance for your help, Niko |
|
From: Julian S. <js...@ac...> - 2012-07-13 11:57:51
|
> So it's precisely commit r12466 which makes valgrind fail on at least Lion. > Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad Thanks for the bisecting. If you use ToT with r12466 backed out, does it work? Can you try with both --tool=none and --tool=memcheck ? Urr, seems like we have a bunch of problems on MacOS to do with OSX 10.8 and XCode 4.3, not just the above bug. Unfortunately I only have a 10.7 based machine to test with. J |
|
From: Nikolas Z. <zim...@kd...> - 2012-07-18 10:18:41
|
Am 13.07.2012 um 13:55 schrieb Julian Seward: > >> So it's precisely commit r12466 which makes valgrind fail on at least Lion. >> Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad > > Thanks for the bisecting. If you use ToT with r12466 backed out, does it > work? Can you try with both --tool=none and --tool=memcheck ? I'll try it as soon as trunk builds again on Mac OSX 10.7: m_debuginfo/readmacho.c: In function 'vgModuleLocal_read_macho_debug_info': m_debuginfo/readmacho.c:1090: error: too few arguments to function 'vgModuleLocal_read_debuginfo_dwarf3' m_debuginfo/readmacho.c:1106: error: too few arguments to function 'vgModuleLocal_new_dwarf3_reader' > Urr, seems like we have a bunch of problems on MacOS to do with OSX 10.8 > and XCode 4.3, not just the above bug. Unfortunately I only have a 10.7 > based machine to test with. Out of curiosity: is it XCode faults? Some non-standard mmap implementation? Thanks, Niko |
|
From: Julian S. <js...@ac...> - 2012-07-18 10:52:17
|
On Wednesday, July 18, 2012, Nikolas Zimmermann wrote: > > Thanks for the bisecting. If you use ToT with r12466 backed out, does it > > work? Can you try with both --tool=none and --tool=memcheck ? > > I'll try it as soon as trunk builds again on Mac OSX 10.7: > m_debuginfo/readmacho.c: In function 'vgModuleLocal_read_macho_debug_info': > m_debuginfo/readmacho.c:1090: error: too few arguments to function > 'vgModuleLocal_read_debuginfo_dwarf3' m_debuginfo/readmacho.c:1106: error: > too few arguments to function 'vgModuleLocal_new_dwarf3_reader' Fixed, r12754. Urr. We should have noticed that earlier. > > Urr, seems like we have a bunch of problems on MacOS to do with OSX 10.8 > > and XCode 4.3, not just the above bug. Unfortunately I only have a 10.7 > > based machine to test with. > > Out of curiosity: is it XCode faults? Some non-standard mmap > implementation? From memory, the list of problems I know about are * assertion failures w.r.t. alignment for 32 bit processes when V is built by XCode 4.3 * link failures in some build configurations (not sure which ones) * #include path problems for system includes, again unclear which configurations * compilation of V never finishes, something to do with building mig, unknown what configuration * the bug you mention, which was itself caused by a fix for a different problem * almost certainly, more problems that I don't know about J |
|
From: Julian S. <js...@ac...> - 2012-08-02 11:15:44
|
On Wednesday, July 18, 2012, Nikolas Zimmermann wrote: > Am 13.07.2012 um 13:55 schrieb Julian Seward: > >> So it's precisely commit r12466 which makes valgrind fail on at least > >> Lion. Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad I backed out r12466 just a few minutes ago, as r12813. So the unmodified ToT should work ok for you now. Pls let me know any other critical failures on OSX asap. I am planning to finalise OSX patches for the upcoming 3.8.0 release in the next 24 hours or so. J |
|
From: Jacob G. <ja...@ad...> - 2012-08-02 17:37:07
|
Hi Julian, I just synced to r12813 and I'm still getting an error when running an arbitrary WebKey layout test under Valgrind (see output below). Nikolas - can you give this a try and see if you get the same results? --- output --- valgrind --dsymutil=yes --leak-check=full --trace-children=yes WebKitBuild/Debug/DumpRenderTree LayoutTests/fast/regions/content-webkit-from-flow-parsing.html ==1322== Memcheck, a memory error detector ==1322== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==1322== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==1322== Command: WebKitBuild/Debug/DumpRenderTree LayoutTests/fast/regions/content-webkit-from-flow-parsing.html ==1322== UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0x55 0x48 0x89 0xE5 0x41 0x56 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==1322== valgrind: Unrecognised instruction at address 0x950fb8c. ==1322== at 0x950FB8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x950FAAA: abort (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x96E7F01: _SCSessionUniverseByUIDAcquireAndLock (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1E28: FSNodeStorageGetAndLockCurrentUniverse (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1C90: FileIDTreeGetAndLockVolumeEntryForDeviceID (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1C46: FSMount::FSMount(unsigned int, FSMountNumberType, short*, unsigned int const*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E0490: PathGetObjectInfo(char const*, unsigned int, unsigned int, short*, unsigned int*, unsigned int*, char*, unsigned int*, unsigned char*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E0278: FSPathMakeRefInternal(unsigned char const*, unsigned int, unsigned int, FSRef*, unsigned char*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x1763637: _CFGetFSRefFromURL (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x17631A7: CFURLGetFSRef (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x176D2E4: _CFBundleCopyInfoDictionaryInResourceForkWithAllocator (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x96FBFE5: GetBugsForOurBundleIDFromCoreservicesd (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96FBD75: _CSCheckFix (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0xA0088E1: _LSApplicationCheckIn (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Lau nchServices.framework/Versions/A/LaunchServices) ==1322== by 0xCCB73AE: _RegisterApplication (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewo rks/HIServices.framework/Versions/A/HIServices) ==1322== by 0xCCB6F0C: GetCurrentProcess (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewo rks/HIServices.framework/Versions/A/HIServices) ==1322== by 0xD4BA62E: _GetAggregateUIMode (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox .framework/Versions/A/HIToolbox) ==1322== by 0xD4BA5E7: IsMenuBarVisible (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox .framework/Versions/A/HIToolbox) ==1322== by 0x1F140EA: _NSInitializeAppContext (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==1322== by 0x1F13626: -[NSApplication init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==1322== by 0x1F1324D: +[NSApplication sharedApplication] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==1322== by 0x100018FC8: main (DumpRenderTree.mm:912) ==1322== Your program just tried to execute an instruction that Valgrind ==1322== did not recognise. There are two possible reasons for this. ==1322== 1. Your program has a bug and erroneously jumped to a non-code ==1322== location. If you are running Memcheck and you just saw a ==1322== warning about a bad jump, it's probably your program's fault. ==1322== 2. The instruction is legitimate but Valgrind doesn't handle it, ==1322== i.e. it's Valgrind's fault. If you think this is the case or ==1322== you are not sure, please let us know and we'll try to fix it. ==1322== Either way, Valgrind will now raise a SIGILL signal which will ==1322== probably kill your program. ==1322== ==1322== Process terminating with default action of signal 4 (SIGILL) ==1322== Illegal opcode at address 0x950FB8C ==1322== at 0x950FB8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x950FAAA: abort (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x96E7F01: _SCSessionUniverseByUIDAcquireAndLock (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1E28: FSNodeStorageGetAndLockCurrentUniverse (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1C90: FileIDTreeGetAndLockVolumeEntryForDeviceID (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E1C46: FSMount::FSMount(unsigned int, FSMountNumberType, short*, unsigned int const*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E0490: PathGetObjectInfo(char const*, unsigned int, unsigned int, short*, unsigned int*, unsigned int*, char*, unsigned int*, unsigned char*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E0278: FSPathMakeRefInternal(unsigned char const*, unsigned int, unsigned int, FSRef*, unsigned char*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x1763637: _CFGetFSRefFromURL (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x17631A7: CFURLGetFSRef (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x176D2E4: _CFBundleCopyInfoDictionaryInResourceForkWithAllocator (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x96FBFE5: GetBugsForOurBundleIDFromCoreservicesd (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== ==1322== HEAP SUMMARY: ==1322== in use at exit: 992,127 bytes in 2,804 blocks ==1322== total heap usage: 4,730 allocs, 1,926 frees, 1,935,862 bytes allocated ==1322== ==1322== 18 bytes in 1 blocks are definitely lost in loss record 303 of 1,486 ==1322== at 0xC8E6: malloc_zone_malloc (vg_replace_malloc.c:273) ==1322== by 0x956E8C6: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x956EDF2: _malloc_initialize (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x956EF2B: malloc_good_size (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x16F9E06: __CFStringChangeSizeMultiple (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x16FE0E7: CFStringAppend (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x171059D: _convertToURLRepresentation (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x1807E56: _CFURLInit (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x1708F81: CFURLCreateWithFileSystemPathRelativeToBase (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x171E388: _CFBundleGetMainBundleAlreadyLocked (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x171E2C5: CFBundleGetMainBundle (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x173FC3B: cacheBundleInfo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== ==1322== 22 bytes in 1 blocks are definitely lost in loss record 309 of 1,486 ==1322== at 0xC8E6: malloc_zone_malloc (vg_replace_malloc.c:273) ==1322== by 0x956E8C6: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib) ==1322== by 0x946B3EF: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==1322== by 0x94684D1: _dispatch_continuation_alloc_from_heap (in /usr/lib/system/libdispatch.dylib) ==1322== by 0x9469A6D: _dispatch_barrier_async_f_slow (in /usr/lib/system/libdispatch.dylib) ==1322== by 0x96B4415: _xpc_connection_create (in /usr/lib/system/libxpc.dylib) ==1322== by 0x96B4D99: xpc_connection_create (in /usr/lib/system/libxpc.dylib) ==1322== by 0x173F9E7: -[NSXPCConnection initWithServiceName:privileged:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x173F57F: __CFXNotificationCenterSetupConnection (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x173F4C0: __CFXNotificationCenterCreate (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x173F399: __CFNotificationCenterGetDistributedCenter_block_invoke_1 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundati on) ==1322== by 0x946B3EF: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==1322== ==1322== 90 bytes in 1 blocks are possibly lost in loss record 1,076 of 1,486 ==1322== at 0xC713: malloc (vg_replace_malloc.c:271) ==1322== by 0x15203EC: operator new(unsigned long) (in /usr/lib/libc++.1.dylib) ==1322== by 0x934D809: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x934F2F9: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x934F411: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x96E63DA: std::pair<unsigned int const, std::string>::pair<unsigned int, char*>(std::pair<unsigned int, char*> const&) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E617E: MachPortTrackerAdd (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E5C3E: SCSession::SCSession(unsigned int, unsigned int) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E576B: SCClientSession::SCClientSession(unsigned int, unsigned int, unsigned int) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E251C: SCClientSession::checkinWithServer(unsigned int*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E2322: connectToCoreServicesD() (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E22A4: getStatus() (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== ==1322== 90 bytes in 1 blocks are possibly lost in loss record 1,077 of 1,486 ==1322== at 0xC713: malloc (vg_replace_malloc.c:271) ==1322== by 0x15203EC: operator new(unsigned long) (in /usr/lib/libc++.1.dylib) ==1322== by 0x934D809: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x934F2F9: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x934F411: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==1322== by 0x96E63DA: std::pair<unsigned int const, std::string>::pair<unsigned int, char*>(std::pair<unsigned int, char*> const&) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E617E: MachPortTrackerAdd (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E5C3E: SCSession::SCSession(unsigned int, unsigned int) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E576B: SCClientSession::SCClientSession(unsigned int, unsigned int, unsigned int) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E57A6: SCClientSession::SCClientSession(unsigned int, unsigned int, unsigned int) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E251C: SCClientSession::checkinWithServer(unsigned int*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== by 0x96E2322: connectToCoreServicesD() (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Car bonCore.framework/Versions/A/CarbonCore) ==1322== ==1322== LEAK SUMMARY: ==1322== definitely lost: 40 bytes in 2 blocks ==1322== indirectly lost: 0 bytes in 0 blocks ==1322== possibly lost: 180 bytes in 2 blocks ==1322== still reachable: 991,907 bytes in 2,800 blocks ==1322== suppressed: 0 bytes in 0 blocks ==1322== Reachable blocks (those to which a pointer was found) are not shown. ==1322== To see them, rerun with: --leak-check=full --show-reachable=yes ==1322== ==1322== For counts of detected and suppressed errors, rerun with: -v ==1322== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) Killed: 9 On 8/2/12 4:07 AM, "Julian Seward" <js...@ac...> wrote: >On Wednesday, July 18, 2012, Nikolas Zimmermann wrote: >> Am 13.07.2012 um 13:55 schrieb Julian Seward: >> >> So it's precisely commit r12466 which makes valgrind fail on at least >> >> Lion. Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad > >I backed out r12466 just a few minutes ago, as r12813. So the >unmodified ToT should work ok for you now. > >Pls let me know any other critical failures on OSX asap. I am >planning to finalise OSX patches for the upcoming 3.8.0 release >in the next 24 hours or so. > >J |
|
From: Nikolas Z. <zim...@kd...> - 2012-07-18 11:00:35
|
Am 18.07.2012 um 12:48 schrieb Julian Seward: > Fixed, r12754. Urr. We should have noticed that earlier. Thanks. I've updated and backed out the problematic revision, and now valgrind works again as expected. So reverting indeed fixes my issues. (Jacob, can you confirm this by building valgrind trunk and reverting the aformentioned revision) >>> Urr, seems like we have a bunch of problems on MacOS to do with OSX 10.8 >>> and XCode 4.3, not just the above bug. Unfortunately I only have a 10.7 >>> based machine to test with. >> >> Out of curiosity: is it XCode faults? Some non-standard mmap >> implementation? > > From memory, the list of problems I know about are > > * assertion failures w.r.t. alignment for 32 bit processes > when V is built by XCode 4.3 > > * link failures in some build configurations (not sure which ones) > > * #include path problems for system includes, again unclear which > configurations > > * compilation of V never finishes, something to do with building mig, > unknown what configuration > > * the bug you mention, which was itself caused by a fix for a different > problem > > * almost certainly, more problems that I don't know about :-) I'm happy to test any patches on Mac, just let me know. Cheers, Niko |