Using hg merge crashes with a bus error in the middle of a merge. I have converted a repository from CVS using the cvs-hg tool. The repo has about 20 branches. Running hg verify reports it as fine. I can switch to any of the branches. But when I try to merge in any of the other branches it reports several conflicts (which is fine), then in the middle of that, it crashes with a bus error. I'm on MacOSX 10.6.8, Python 2.6.4, Mercurial 1.9+20110704 --------- Process: Python [6724] Path: /System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.ap p/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86-64 (Native) Parent Process: zsh [4533] Date/Time: 2011-08-02 15:55:38.172 +0200 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Sleep/Wake UUID: 952127F2-D444-4C96-8749-662E58E566A6 Interval Since Last Report: 505698 sec Crashes Since Last Report: 8 Per-App Crashes Since Last Report: 4 Anonymous UUID: 6610F33F-70A4-4263-B198-4A2CA2E43C04 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000101ea45e0 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 ??? 0x0000000101ea45e0 0 + 4327097824 1 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 2 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 3 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 4 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 5 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 6 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 7 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 8 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 9 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 10 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 11 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 12 org.python.python 0x000000010002c88f PyClassMethod_New + 1666 13 org.python.python 0x000000010000aff3 PyObject_Call + 112 14 org.python.python 0x000000010008a54e PyEval_EvalFrameEx + 20380 15 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 16 org.python.python 0x000000010002c88f PyClassMethod_New + 1666 17 org.python.python 0x000000010000aff3 PyObject_Call + 112 18 org.python.python 0x000000010008a54e PyEval_EvalFrameEx + 20380 19 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 20 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 21 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 22 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 23 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 24 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 25 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 26 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 27 org.python.python 0x000000010008935e PyEval_EvalFrameEx + 15788 28 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 29 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 30 org.python.python 0x00000001000892e1 PyEval_EvalFrameEx + 15663 31 org.python.python 0x000000010008acce PyEval_EvalCodeEx + 1803 32 org.python.python 0x000000010008ad61 PyEval_EvalCode + 54 33 org.python.python 0x00000001000a265a Py_CompileString + 78 34 org.python.python 0x00000001000a2723 PyRun_FileExFlags + 150 35 org.python.python 0x00000001000a423d PyRun_SimpleFileExFlags + 704 36 org.python.python 0x00000001000b0286 Py_Main + 2718 37 org.python.python.app 0x0000000100000e6c start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000101ea4990 rbx: 0x000000000000006f rcx: 0x0000000101ed38d6 rdx: 0x0000000000000022 rdi: 0x00000001001163b0 rsi: 0x000000000000022f rbp: 0x00007fff5fbfc010 rsp: 0x00007fff5fbfbdd8 r8: 0x0000000000000000 r9: 0x0000000101ecdfc0 r10: 0x0000000000000000 r11: 0x000000010002d032 r12: 0x0000000101ed6198 r13: 0x0000000000000022 r14: 0x0000000101ed5f70 r15: 0x0000000001ed36a4 rip: 0x0000000101ea45e0 rfl: 0x0000000000010246 cr2: 0x0000000101ea45e0 Binary Images: 0x100000000 - 0x100000ff7 org.python.python.app 2.6 (2.6) <3F4A329D-3EF9-A736-6F3D- 67A4B39AE8DE> /System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.ap p/Contents/MacOS/Python 0x100004000 - 0x100114ff7 org.python.python 2.6.1 (2.6.1) <126DA8FF-5BC2-8788-51E3- D7A29A3F9F0F> /System/Library/Frameworks/Python.framework/Versions/2.6/Python 0x1001d7000 - 0x1001d9ff7 readline.so ??? (???) <200F07EB- D7AC-BE0E-165E-A84266ECC26F> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/readline.so 0x1001df000 - 0x1001e0ff7 time.so ??? (???) <80513398-F49E- 79D1-5014-514361869D40> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/time.so 0x1001f8000 - 0x1001f9fff _random.so ??? (???) <FC54824D- 3F1F-D538-DBF8-05E393A696B6> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_random.so 0x1004a5000 - 0x1004a8fff _ssl.so ??? (???) <B10EAC68-E620- 8A1A-0219-68CCABC29CA2> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_ssl.so 0x1006f0000 - 0x1006f1fff _locale.so ??? (???) <43F84ED0- 3A85-1997-8098-2D3870B4012D> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_locale.so 0x1006f5000 - 0x1006f6ff7 _functools.so ??? (???) <97A294C7- 290C-9746-B294-275516490F40> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_functools.so 0x1006fa000 - 0x1006fafff grp.so ??? (???) <AEBF325A-8034- 28EC-2813-EAD4D9E7B259> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/grp.so 0x1006fe000 - 0x1006fffff fcntl.so ??? (???) <B58E4C0C-1065- E37B-5334-DFDBAD20655C> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/fcntl.so 0x100703000 - 0x100704fff +osutil.so ??? (???) <BB46298C-0521- 3656-86F7-837CE2DF16CA> /Library/Python/2.6/site-packages/mercurial/osutil.so 0x100707000 - 0x100709fe7 binascii.so ??? (???) <D7D60C49- DEFA-5DB1-83B0-F91347966BC8> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/binascii.so 0x1007cd000 - 0x1007d1ff7 _struct.so ??? (???) <B4DD710D- 1511-99F0-66AE-329185E2B88C> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_struct.so 0x1007d7000 - 0x1007daff7 zlib.so ??? (???) <647721E3-67B5- 8CD0-3A78-060FF9C80924> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/zlib.so 0x1007df000 - 0x1007e0ff7 _hashlib.so ??? (???) <7F6E55A6- 9FFF-0C47-2D65-76900C63C294> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_hashlib.so 0x1007e4000 - 0x1007e5fff +parsers.so ??? (???) <DA9FCF23- A6B7-3B5F-9978-29F3E2B95A16> /Library/Python/2.6/site-packages/mercurial/parsers.so 0x1007e8000 - 0x1007e9fff +mpatch.so ??? (???) <769D4F55-4E21- 3891-A386-772E59F55E02> /Library/Python/2.6/site-packages/mercurial/mpatch.so 0x1007ec000 - 0x1007edfff +bdiff.so ??? (???) <5AF2096B-A8A2- 38FB-B97A-45884A618509> /Library/Python/2.6/site-packages/mercurial/bdiff.so 0x1007f0000 - 0x1007f7fff _socket.so ??? (???) <BA49272E- D7AA-158E-C95E-366B6349C046> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_socket.so 0x1010d3000 - 0x1010d4fff cStringIO.so ??? (???) <0C7D1D15- 4241-99A9-7671-A3CF105C2EBB> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/cStringIO.so 0x1010d9000 - 0x1010d9fff _weakref.so ??? (???) <2A4A85EC- 30E5-11FB-40B5-544EEF7CD1C0> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_weakref.so 0x1010dd000 - 0x1010e2fff itertools.so ??? (???) <9287854F- 7F2B-D4AF-FCA3-EB69DA821DA9> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/itertools.so 0x1010ea000 - 0x1010edfff operator.so ??? (???) <ADC2B876- 4E3F-93E3-D83C-4B8A3AEAAE2B> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/operator.so 0x1010f3000 - 0x1010f4ff7 _heapq.so ??? (???) <9D1346ED-4A36- F835-2C9C-7303DEF1CFAA> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/_heapq.so 0x1015f0000 - 0x1015f5ff7 array.so ??? (???) <8DDEB5A1-671C- 5868-9F06-21BA81D9DBAE> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/array.so 0x1017f1000 - 0x1017f3ff7 math.so ??? (???) <54D066FD-A9F9- EA69-8C3C-CE83DF68C58A> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/math.so 0x10243a000 - 0x102456fe7 libedit.2.dylib 2.11.0 (compatibility 2.0.0) <DB35EEA3-A6D3- 7D82-6EFB-70383A153E0A> /usr/lib/libedit.2.dylib 0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) <63B47435-46CF- 3D2D-F7F4-7FE77DEEFE06> /usr/lib/dyld 0x7fff80047000 - 0x7fff80205fff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <4274FC73- A257-3A56-4293-5968F3428854> /usr/lib/libicucore.A.dylib 0x7fff80645000 - 0x7fff806a5fe7 com.apple.framework.IOKit 2.0 (???) <4F071EF0-8260-01E9-C641- 830E582FA416> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff806a6000 - 0x7fff8077afe7 com.apple.CFNetwork 454.12.4 (454.12.4) <C83E2BA1-1818-B3E8- 5334-860AD21D1C80> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNe twork.framework/Versions/A/ CFNetwork 0x7fff8077b000 - 0x7fff8083cfef com.apple.ColorSync 4.6.6 (4.6.6) <BB2C5813-C61D-3CBA-A8F7- 0E59E46EBEE8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ColorSync.framework/Vers ions/A/ColorSync 0x7fff80873000 - 0x7fff80cb6fef libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <0CC61C98-FF51- 67B3-F3D8-C5E430C201A9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib .framework/Versions/A/libLA PACK.dylib 0x7fff80da2000 - 0x7fff80e0cfe7 libvMisc.dylib 268.0.1 (compatibility 1.0.0) <AF0EA96D-000F- 8C12-B952-CB7E00566E08> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib .framework/Versions/A/libvM isc.dylib 0x7fff80e0d000 - 0x7fff80e2efff libresolv.9.dylib 41.0.0 (compatibility 1.0.0) <9F322F47-0584- CB7D-5B73-9EBD670851CD> /usr/lib/libresolv.9.dylib 0x7fff80e5e000 - 0x7fff80f14ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D- 1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib 0x7fff80f15000 - 0x7fff80f15ff7 com.apple.Accelerate 1.6 (Accelerate 1.6) <15DF8B4A-96B2-CB4E- 368D-DEC7DF6B62BB> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff80fe7000 - 0x7fff80ff8ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <97019C74-161A-3488- 41EC-A6CA8738418C> /usr/lib/libz.1.dylib 0x7fff80ff9000 - 0x7fff8100eff7 com.apple.LangAnalysis 1.6.6 (1.6.6) <1AE1FE8F-2204-4410-C94E- 0E93B003BEDA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/LangAnalysis.framework/V ersions/A/LangAnalysis 0x7fff8100f000 - 0x7fff810a9fe7 com.apple.ApplicationServices.ATS 275.16 (???) <4B70A2FC-1902- 5F27-5C3B-5C78C283C6EA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ATS.framework/Versions/A /ATS 0x7fff81aeb000 - 0x7fff81aebff7 com.apple.ApplicationServices 38 (38) <10A0B9E9-4988-03D4- FC56-DDE231A02C63> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Applicat ionServices 0x7fff8207d000 - 0x7fff820a5fff com.apple.DictionaryServices 1.1.2 (1.1.2) <E9269069-93FA- 2B71-F9BA-FDDD23C4A65E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Dict ionaryServices.framework/Ve rsions/A/DictionaryServices 0x7fff820a6000 - 0x7fff823dafef com.apple.CoreServices.CarbonCore 861.39 (861.39) <1386A24D- DD15-5903-057E-4A224FAF580B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Carb onCore.framework/Versions/A /CarbonCore 0x7fff82eca000 - 0x7fff82eccfff libRadiance.dylib ??? (???) <A9DB4D5D-4072-971B-DEF6- DDE645F415EA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/Resources/libRadiance.dylib 0x7fff830be000 - 0x7fff831ddfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <14115D29- 432B-CF02-6B24-A60CC533A09E> /usr/lib/libcrypto.0.9.8.dylib 0x7fff832b1000 - 0x7fff8336afff libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <2C5ED312-E646- 9ADE-73A9-6199A2A43150> /usr/lib/libsqlite3.dylib 0x7fff8336b000 - 0x7fff833beff7 com.apple.HIServices 1.8.3 (???) <F6E0C7A7-C11D-0096-4DDA- 2C77793AA6CD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/HIServices.framework/Ver sions/A/HIServices 0x7fff8356b000 - 0x7fff83579ff7 libkxld.dylib ??? (???) <8145A534- 95CC-9F3C-B78B-AC9898F38C6F> /usr/lib/system/libkxld.dylib 0x7fff83697000 - 0x7fff83858fef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1- 89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib 0x7fff83859000 - 0x7fff839d0fe7 com.apple.CoreFoundation 6.6.5 (550.43) <31A1C118-AD96-0A11- 8BDF-BD55B9940EDC> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundatio n 0x7fff839d1000 - 0x7fff839d7ff7 com.apple.DiskArbitration 2.3 (2.3) <857F6E43-1EF4-7D53-351B- 10DE0A8F992A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitrat ion 0x7fff83b8a000 - 0x7fff83d48ff7 com.apple.ImageIO.framework 3.0.4 (3.0.4) <0A4F51A1-4502-767B- 8A4E-F14C6214EF88> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/ImageIO 0x7fff83d90000 - 0x7fff83ddcfff libauto.dylib ??? (???) <F7221B46- DC4F-3153-CE61-7F52C8C293CF> /usr/lib/libauto.dylib 0x7fff83e1c000 - 0x7fff83eacfff com.apple.SearchKit 1.3.0 (1.3.0) <4175DC31-1506-228A-08FD- C704AC9DF642> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Sear chKit.framework/Versions/A/ SearchKit 0x7fff84160000 - 0x7fff84200fff com.apple.LaunchServices 362.3 (362.3) <B90B7C31-FEF8-3C26- BFB3-D8A48BD2C0DA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Laun chServices.framework/Versio ns/A/LaunchServices 0x7fff8523c000 - 0x7fff8527dfef com.apple.QD 3.36 (???) <5DC41E81- 32C9-65B2-5528-B33E934D5BB4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/QD.framework/Versions/A/ QD 0x7fff852e7000 - 0x7fff852ebff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673- FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fff8534d000 - 0x7fff8534eff7 com.apple.TrustEvaluationAgent 1.1 (1) <5952A9FA-BC2B-16EF- 91A7-43902A5C07B6> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/ TrustEvaluationAgent 0x7fff8534f000 - 0x7fff8538cff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <F743389F-F25A- A77D-4FCA-D6B01AF2EE6D> /usr/lib/libssl.0.9.8.dylib 0x7fff8538d000 - 0x7fff8544efff libFontParser.dylib ??? (???) <A00BB0A7-E46C-1D07-1391- 194745566C7E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ATS.framework/Versions/A /Resources/libFontParser.dylib 0x7fff855ff000 - 0x7fff85684ff7 com.apple.print.framework.PrintCore 6.3 (312.7) <CDFE82DD- D811-A091-179F-6E76069B432D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/PrintCore.framework/Vers ions/A/PrintCore 0x7fff858e3000 - 0x7fff858e3ff7 com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <4CCE5D69-F1B3- 8FD3-1483-E0271DB2CCF3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib .framework/Versions/A/vecLi b 0x7fff858e4000 - 0x7fff858f8ff7 com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <621B7415-A0B9-07A7-F313-36BEEDD7B132> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/SpeechSynthesis.framewor k/Versions/A/SpeechSynthesis 0x7fff85cb9000 - 0x7fff85f42ff7 com.apple.security 6.1.2 (55002) <4419AFFC-DAE7-873E-6A7D- 5C9A5A4497A6> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff85f5e000 - 0x7fff85f74fef libbsm.0.dylib ??? (???) <42D3023A- A1F7-4121-6417- FCC6B51B3E90> /usr/lib/libbsm.0.dylib 0x7fff85f78000 - 0x7fff861fafe7 com.apple.Foundation 6.6.7 (751.62) <6F2A5BBF-6990-D561-2928- AD61E94036D9> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff861fb000 - 0x7fff86222ff7 libJPEG.dylib ??? (???) <46A413EA- 4FD1-A050-2EF0-6279F3EAD581> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/Resources/libJPEG.dylib 0x7fff86223000 - 0x7fff8633afef libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <1B27AFDD-DF87- 2009-170E-C129E1572E8B> /usr/lib/libxml2.2.dylib 0x7fff8661e000 - 0x7fff866dbfff com.apple.CoreServices.OSServices 359.2 (359.2) <BBB8888E- 18DE-5D09-3C3A-F4C029EC7886> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSSe rvices.framework/Versions/A /OSServices 0x7fff866dc000 - 0x7fff866dcff7 com.apple.CoreServices 44 (44) <DC7400FB-851E-7B8A-5BF6- 6F50094302FB> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff86736000 - 0x7fff86777fff com.apple.SystemConfiguration 1.10.8 (1.10.2) <78D48D27-A9C4- 62CA-2803-D0BBED82855A> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemCo nfiguration 0x7fff86778000 - 0x7fff86795ff7 libPng.dylib ??? (???) <6D8E515B- E0A2-2BA1-9CAC-8CB8A8B35879> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/Resources/libPng.dylib 0x7fff867bc000 - 0x7fff8686cfff edu.mit.Kerberos 6.5.11 (6.5.11) <085D80F5-C9DC-E252-C21B- 03295E660C91> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff8686d000 - 0x7fff868b7ff7 com.apple.Metadata 10.6.3 (507.15) <2EF19055-D7AE-4D77-E589- 7B71B0BC1E59> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Meta data.framework/Versions/A/M etadata 0x7fff8704d000 - 0x7fff87087fff libcups.2.dylib 2.8.0 (compatibility 2.0.0) <7982734A-B66B- 44AA-DEEC-364D2C10009B> /usr/lib/libcups.2.dylib 0x7fff87545000 - 0x7fff8758dff7 libvDSP.dylib 268.0.1 (compatibility 1.0.0) <98FC4457-F405- 0262-00F7-56119CA107B6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib .framework/Versions/A/libvD SP.dylib 0x7fff8771d000 - 0x7fff87748ff7 libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <8AB4CA9E-435A- 33DA-7041-904BA7FA11D5> /usr/lib/libxslt.1.dylib 0x7fff87c04000 - 0x7fff87c09fff libGIF.dylib ??? (???) <201B8077- B5CC-11AA-E1B0-1D057ABE416A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/Resources/libGIF.dylib 0x7fff88087000 - 0x7fff880c6fef libncurses.5.4.dylib 5.4.0 (compatibility 5.4.0) <9D53BE03- 6D81-D0CB-F657-4E842E69A66A> /usr/lib/libncurses.5.4.dylib 0x7fff88119000 - 0x7fff88923fe7 libBLAS.dylib 219.0.0 (compatibility 1.0.0) <FC941ECB-71D0- FAE3-DCBF-C5A619E594B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib .framework/Versions/A/libBL AS.dylib 0x7fff88b48000 - 0x7fff88b97fef libTIFF.dylib ??? (???) <1E2593D1- A7F6-84C6-DF8F-0B46AE445926> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/ImageIO.framework/Versio ns/A/Resources/libTIFF.dylib 0x7fff88caa000 - 0x7fff88d27fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08- FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib 0x7fff88d76000 - 0x7fff89472ff7 com.apple.CoreGraphics 1.545.0 (???) <58D597B1-EB3B-710E-0B8C- EC114D54E11B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/CoreGraphics.framework/V ersions/A/CoreGraphics 0x7fff899af000 - 0x7fff89a8cfff com.apple.vImage 4.1 (4.1) <C3F44AA9-6F71-0684-2686- D3BBC903F020> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage .framework/Versions/A/vImag e 0x7fff89a8d000 - 0x7fff89b0bff7 com.apple.CoreText 151.10 (???) <54961997-55D8-DC0F-2634- 674E452D5A8E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Framewor ks/CoreText.framework/Versi ons/A/CoreText 0x7fff89b0c000 - 0x7fff89b1bfff com.apple.NetFS 3.2.2 (3.2.2) <7CCBD70E-BF31-A7A7-DB98- 230687773145> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff89d90000 - 0x7fff89dcbfff com.apple.AE 496.5 (496.5) <208DF391-4DE6-81ED-C697- 14A2930D1BC6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.f ramework/Versions/A/AE 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E- A4FE4D69DB69> /usr/lib/libSystem.B.dylib Model: MacBookPro6,2, BootROM MBP61.0057.B0C, 2 processors, Intel Core i5, 2.4 GHz, 8 GB, SMC 1.58f16 Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 256 MB Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.10.131.42.4) Bluetooth: Version 2.4.5f3, 2 service, 19 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: INTEL SSDSA2M160G2GC, 149,05 GB Serial ATA Device: ST9500420AS, 465,76 GB USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 5 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8218, 0xfa113000 / 8 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x0237, 0xfa120000 / 4 USB Device: Internal Memory Card Reader, 0x05ac (Apple Inc.), 0x8403, 0xfa130000 / 3 USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0xfd120000 / 4 USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8507, 0xfd110000 / 3
Is this 100% reproducible with the same stacktrace every time? Do you see other problems with Mercurial or other programs on the machine?
Yes, it happens every time. Stacktraces look identical. I haven't used Mercurial or Python so far, but I'm not aware of problems with other programs on my machine. I have upgraded to Mercurial 1.9.1+20110818. I also tried to install Python 2.7.2 and install Mercurial from source. It didn't change anything. I tried cloning some other repo from the net, and merging worked fine there. I also found another Mac, and also installed Mercurial 1.9.1, and there merging with my repo also works. The difference is, that that Mac is still on MacOSX 10.5, so it's using Python 2.5 instead of 2.6. So I suspect it is some combination of my machine and that specific repo. Not really sure how to debug this, though. Some other strange thing I found, some of the output of the merge command is different on those two machines. 10.5: warning: conflicts during merge. 10.6: merge: warning: conflicts during merge (the dot at the end is missing, and it is prefixed with merge:) Which of the two is correct? The mercurial version on both systems is the same, only Python and the OS differs... The other difference is, on the system where it works it asks me about some binary file: no tool found to merge cfg/pwd_BuildCenter.pwd keep (l)ocal or take (o)ther? On my machine it simply says: merging cfg/pwd_BuildCenter.pwd merging cfg/pwd_BuildCenter.pwd failed!
Found it. The culprit was a program I installed several months ago and completely forgot about. It's called SourceTree.app. For whatever reason it installed itself into my ~/.hgrc as a merge tool. It was that external tool that crashed. Removing it fixed the problem.
I've been investigating this report as I'm the author of SourceTree. I do still think this is a Mercurial issue, but it only occurs on certain merges, and when there are settings specified in [merge-tools]. To reproduce it: 1. Clone from https://sinbad@bitbucket.org/sinbad/ogre 2. Update to changeset 70e5eef9919e830aea8f78ecdeb70e1c388c50a1 3. Make sure you have this setting in your ~/.hgrc (a fairly standard one on OS X), references the opendiff-w script as described here: http://mercurial.selenic.com/wiki/ExtdiffExtension [merge-tools] filemerge.executable=opendiff-w filemerge.args=$local $other -ancestor $base -merge $output 4. Execute 'hg merge -y 6f86381d574516fc311b23daf9955c53f979fe9f' 5. You should get a segfault just after "merging OgreMain/include/OgreCompositionTechnique.h" If you remove the content of [merge-tools] in ~/.hgrc, the merge completes successfully. It's odd that it's a segfault in Python rather than a Python stack trace. This is with Mercurial 1.9.1+20110818 but I've had it reported in the same case on 1.8.4 too. I'm not sure what it is about this particular merge, or perhaps the one reported by the OP. I've tested with lots of other cases, including text and binary conflicts, and have not seen this problem. It's just a coincidence that someone on the Ogre project (which I used to run) reported a similar issue this week. I hope that helps you diagnose it! I don't think it's a SourceTree issue, it just seems to be a problem with the [merge-tools] content. I can turn it on and off just by deleting & re-inserting those 2 lines above.
First the overall perspective: Mercurial is written Python (at least the parts involved here), so there is no way it should be able to cause a Python crash. It is possible that Mercurial can work around the issue, but it seems like the real bug must be in Python. Some wild shots in different directions: Since you are using the opendiff-w hack I assume that opendiff - and SourceTree - (double?) forks but doesn't close stdout (reopening at /dev/null or something). A command line option for running a single process without forking or waiting for the app to finish would be much better and more reliable. I don't know if these problems are related to that. Mercurials handling of stdout for sub processes changed in 1.9 and could perhaps give a hint where we should look - but you see exactly the same failure with 1.8.4? Do the merge tool write a lot of data to stdout/stderr? I assume you are running Mercurial from source? Can you try to do something like this: --- a/mercurial/util.py +++ b/mercurial/util.py @@ -355,9 +355,11 @@ env.update((k, py2shell(v)) for k, v in environ.iteritems()) env['HG'] = hgexecutable() if out is None or out == sys.__stdout__: + print 'call', (cmd, closefds, env, cwd) rc = subprocess.call(cmd, shell=True, close_fds=closefds, env=env, cwd=cwd) else: + print 'Popen', (cmd, closefds, env, cwd) proc = subprocess.Popen(cmd, shell=True, close_fds=closefds, env=env, cwd=cwd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) and see if you can reproduce the problem with a little python script with just the relevant lines and values from this function? Is it possible to run Python in a debugger with debug symbols and investigate where and why it crashes?
I agree that there must be an issue in Python here for there to be a segfault, it's just that since a change to the [mercurial-tools] section of .hgrc can turn it on/off, it might be possible to work around it in Mercurial in the short term, given how nasty it is. > Since you are using the opendiff-w hack I assume that opendiff - and SourceTree - (double?) forks but doesn't close stdout (reopening at /dev/null or something). In this case, I actually eliminated SourceTree from the equation entirely and simply had FileMerge configured in [merge-tools], with opendiff-w being exactly the same as detailed in the Mercurial wiki: http://mercurial.selenic.com/wiki/ExtdiffExtension. It just so happens that SourceTree can set up [merge-tool] entries too which is why this was reported I think, but I can re-create it with a clean hgrc with nothing special in it except for that completely standard opendiff-w setting. > Mercurials handling of stdout for sub processes changed in 1.9 and could > perhaps give a hint where we should look - but you see exactly the same > failure with 1.8.4? Actually, that was reported by the Ogre team member who initially encountered it, but I've just tried it myself by reverting to 1.8.4 and it actually works fine. So yes, 1.9's changes do appear to be triggering this. I've been testing with the release versions of Mercurial and Python so far. I can try to dig a bit deeper, but I'm not a Python expert, I was hoping that someone more experienced in this area would be able to reproduce it using the steps I posted. Thanks Steve
> In this case, I actually eliminated SourceTree from the equation entirely > and simply had FileMerge configured in [merge-tools], with opendiff-w being > exactly the same as detailed in the Mercurial wiki: > http://mercurial.selenic.com/wiki/ExtdiffExtension. It just so happens that > SourceTree can set up [merge-tool] entries too which is why this was > reported I think, but I can re-create it with a clean hgrc with nothing > special in it except for that completely standard opendiff-w setting. Ok, so SourceTree isn't used as merge tool - it just configures the opendiff/FileMerge tool with opendiff-w? I don't know how "standard" opendiff-w is - it is just a hack or workaround that happens to be described on the wiki. FileMerge might be standard, but I assume it is a closed-source tool? It would be nice to have a simple open source tool to reproduce the issue. > Actually, that was reported by the Ogre team member who initially > encountered it, but I've just tried it myself by reverting to 1.8.4 and it > actually works fine. So yes, 1.9's changes do appear to be triggering this. Can you try to bisect between 1.8.4 and 1.9 and see exactly which changeset introduced the problem?
First of all, sorry to Steve for dragging him into this. It has actually nothing to do with him or his application (which btw is great, just bought it :) I can reproduce the ogre crash on my machine. Some observations: - the filemerge.executable script is never called. Actually, you can put anything there, as long as it exists and is executable, and it still crashes. - I tried the small util.py patch, and found that the system() method is never called at all. I will try if I can find a difference in running it with and without that merge- tools config entry.
OK. Now this is definitely beyond me. Python crashes, while doing a return from a function.... In mercurial.filemerge.py, there is _picktool() and inside that is a check() function. It crashes while returning from that function. Try this: diff -r 4a43e23b8c55 mercurial/filemerge.py --- a/mercurial/filemerge.py Mon Aug 01 23:58:50 2011 +0200 +++ b/mercurial/filemerge.py Mon Aug 29 00:00:22 2011 +0200 @@ -53,7 +53,9 @@ elif not util.gui() and _toolbool(ui, tool, "gui"): ui.warn(_("tool %s requires a GUI\n") % tmsg) else: + print 'returning True from check()' return True + print 'returning False from check()' return False # forcemerge comes from command line arguments, highest priority @@ -93,9 +95,12 @@ tools.insert(0, (None, uimerge)) # highest priority tools.append((None, "hgmerge")) # the old default, if found for p, t in tools: + print 'calling check()' if check(t, None, symlink, binary): + print 'returned True from check()' toolpath = _findtool(ui, t) return (t, '"' + toolpath + '"') + print 'returned False from check()' # internal merge as last resort return (not (symlink or binary) and "internal:merge" or None, None) This will print: .... merging OgreMain/include/OgreBillboardSet.h calling check() returning True from check() returned True from check() merging OgreMain/include/OgreCamera.h calling check() returning True from check() zsh: segmentation fault hg merge -y 6f86381d574516fc311b23daf9955c53f979fe9f As you see, the print before the return is executed, the print after the function call isn't.
Bisecting gives me this: The first bad revision is: changeset: 13734:16118b4859a1 user: Dan Villiom Podlaski Christiansen <danchr@gmail.com> date: Wed Mar 23 09:43:34 2011 +0100 summary: util: add Mac-specific check whether we're in a GUI session (issue2553) This change introduces a Mac specific check into the gui() function in util.py. And sure enough, this function is called from the check() function which causes the crash. If I replace the util.gui() call with a False, it doesn't crash anymore.
Ok, I was wrong. Native C code is involved here. http://www.selenic.com/hg/rev/16118b4859a1 . The function name CGSessionCopyCurrentDictionary indicates that it allocates a copy that must be freed/released, but it seems like it is a reference type and other code snippets that calls it doesn't release it. Is there a valgrind for OS/X? Or can you try to uncomment CFRelease and build the extension and call the function a million times and see if it leaks? CCing Dan.
As best I can tell, 16118b4859a1 is correct. I tried running leaks[1] on a binary compiled from the source included below. It revealed two things: 1) Every call to CGSessionCopyCurrentDictionary() does indeed return a distinct instance and 2) neglecting to call CFRelease() on the result does indeed leak. Please try commenting out the call to CFRelease(), and see if it fixes the crash. If it does, we could change the code so that CGSessionCopyCurrentDictionary() is only ever called once, and just live with the leak. To reproduce, copy the C code to ‘test.c’ and do in one terminal: $ clang -framework ApplicationServices test.c -o test $ MallocStackLogging=1 ./test Copy the PID from the malloc debug output, and do in another terminal: $ leaks $PID [1] http://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPage s/man1/leaks.1.html --- #include <ApplicationServices/ApplicationServices.h> int main() { CFDictionaryRef dict1 = CGSessionCopyCurrentDictionary(); printf("%p\n", dict1); CFDictionaryRef dict2 = CGSessionCopyCurrentDictionary(); printf("%p\n", dict2); CFRelease(dict1); // CFRelease(dict2); dict1 = dict2 = NULL; sleep(15); }
Oh, wait, on second thought, perhaps the issue is that we don't increase the reference count of Py_True and Py_False before returning them? The fact that the crash is deep within the Python VM and nowhere near this code suggests so…
Dan, I think you are right. That do however raise the queestion why the problem seemed to be related to some special merge tool configurations. Shouldn't all 1.9.x Mac users have experienced this frequently? (By the way: Would it be an idea to move this function to ctypes instead?)
The crash only occurs rarely with certain merges for some reason. When I was trying to reproduce this I did lots of merges with 1.9 and never hit the problem, that's why I was very specific about naming the Ogre merge which would reproduce it. So I think it's a minority of merges that trigger this problem, which combined with the fact that you have to have [merge-tools] configured, means that not everyone will be seeing it all the time.
Dan, I just checked. The crash has nothing to do with the CGSessionCopyCurrentDictionary() call. I can comment out the entire isgui() function, and just return Py_True, and it still crashes. When I uncomment it again and replace the two returns with a Py_RETURN_TRUE resp. Py_RETURN_FALSE it does NOT crash anymore. Is that the correct thing to do? I don't know anything about Python. I think Dan is right. This looks like some memory gets corrupted somewhere, and that can be due to bad reference counting. While the crash was very consistent in its occurrence, it did NOT always happen at the same file. Sometimes it crashed earlier, sometimes later. As to why this depends on merge-tool configuration, that is quite easy. The isgui() function is simply not called when there is no merge-tools configuration.
> When I uncomment it again and replace the two returns with a Py_RETURN_TRUE resp. > Py_RETURN_FALSE it does NOT crash anymore. Is that the correct thing to do? I think so. > As to why this depends on merge-tool configuration, that is quite easy. The isgui() > function is simply not called when there is no merge-tools configuration. Yes, but (almost) _any_ merge tool configuration should be able to trig this issue.
> Yes, but (almost) _any_ merge tool configuration should be able to trig this issue. Yea, it does. I was using /bin/true as my filemerge.executable :) Any merge-tool config triggers the memory corruption, but you still need a merge that is peculiar enough (probably just big enough) to get it's memory trampled over by whatever the bad reference counting thingy in the isgui() function triggers.
Just to check, will this issue be updated when this is resolved in Mercurial? I'm currently holding off officially supporting Mercurial 1.9 in SourceTree because of this (and because of a couple of extensions that broke with 1.9). 1.9.2 doesn't appear to have included the fix suggested here.
Yes, this issue will be updated. We are waiting for someone who have a Mac to create a real patch, test it, and contribute it.
OK, I thought the discussion here was enough. I'll have a go.
I made the change marc.guenther suggested in a local copy, and it appeared to work for me too. I've submitted it to the mailing list. I'm new to building Mercurial from source though so I'd feel better if someone else checked it too (attached).
Do we have a fix for this yet?
Steve Streeting attached a patch to this issue, although it probably should have been sent to the list. It looks good to me.
Hmm, perhaps something is wrong with the rendering of the HTML next to the file attachment dialog in his browser.
No sign of the patch in the list archives or in the moderation queue, please resend.
I sent Steve's patch to the list. I sent it from my work address, though, so it seems it's stuck in the moderation queue.
Hmm, I did send it to mercurial-devel@selenic.com (cc'ed to myself, which I received) on 8th Sept. Maybe mine was stuck in the moderation queue too?
The patch made it to the list. FWIW I didn't get receive your patch either…
Fixed by http://selenic.com/repo/hg/rev/258eee414ab7 Steve Streeting <steve@stevestreeting.com> osutil: avoid accidentally destroying the True object in isgui (issue2937) (please test the fix)
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:22 EDT --- This bug was previously known as _bug_ 2937 at http://mercurial.selenic.com/bts/issue2937 Imported an attachment (id=1572)