Apache OpenOffice (AOO) Bugzilla – Issue 72248
vcl compiled with debug crashes
Last modified: 2007-07-09 22:02:54 UTC
Hi, Stephan reported that vcl when compiled with debug=t in aquavcl01 crashes. The stack was very simply - it crashed in the constructor of AquaSalBitmap, see bellow. I identified that the problem is in vcl/aqua/source/gdi/salbmp.cxx. It crashes in the constructor of AquaSalBitmap which is declared as: class AquaSalBitmap : public SalBitmap { public: CGContextRef mxGraphicContext; BitmapPalette maPalette; basebmp::RawMemorySharedArray maUserBuffer; basebmp::RawMemorySharedArray maContextBuffer; sal_uInt16 mnBits; ... Notice the usage of basebmp::RawMemorySharedArray. It looked suspect for us, but we do not know of any other place where it is used or how to use it properly. The other question is why I'm now getting completely different stack here with complete vcl debug=t build: ============================== SAL_FRAME_STYLE_INTRO ============================== Reading symbols for shared libraries . done Reading symbols for shared libraries . done sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392e200: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug Bounds changed event >*>_> GetClientSize >*>_> GetClientSize >*>_> SetBackgroundBitmap >*>_> GetParent sofficebin(4692,0xa000cfc0) malloc: *** error for object 0x392b1c0: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sofficebin(4692,0xa000cfc0) malloc: *** set a breakpoint in szone_error to debug Malloc warnigns looks suspect as well. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3f800000 0x903318ac in path_element () (gdb) where #0 0x903318ac in path_element () #1 0x90388c63 in CGPathAddPath () #2 0x904fbe7b in CGContextAddPath () #3 0x0124da42 in AquaSalGraphics::InitContextForPainting (this=0x392bb40, xContext=0x39563d0) at /Users/pavel/BUILD/AQUA/BuildDir/ooo_SRC680_m195_src/vcl/aqua/source/gdi/salgdiutils.cxx:89 #4 0x0124dc94 in AquaSalGraphics::BeginGraphics (this=0x392bb40) at /Users/pavel/BUILD/AQUA/ BuildDir/ooo_SRC680_m195_src/vcl/aqua/source/gdi/salgdiutils.cxx:145 #5 0x01253708 in AquaSalGraphics::drawBitmap (this=0x392bb40, pPosAry=0xbfffe51c, rSalBitmap=@0x3956800) at /Users/pavel/BUILD/AQUA/BuildDir/ooo_SRC680_m195_src/vcl/aqua/ source/gdi/salgdi.cxx:577 #6 0x01253620 in AquaSalGraphics::copyBits (this=0x392bb40, pPosAry=0xbfffe6a4, pSrcGraphics=0x392bda0) at /Users/pavel/BUILD/AQUA/BuildDir/ooo_SRC680_m195_src/vcl/aqua/ source/gdi/salgdi.cxx:546 #7 0x0111fa31 in SalGraphics::CopyBits (this=0x392bb40, pPosAry=0xbfffe6a4, pSrcGraphics=0x392bda0, pOutDev=0x2fd5624, pSrcOutDev=0x2fd574c) at /Users/pavel/BUILD/ AQUA/BuildDir/ooo_SRC680_m195_src/vcl/source/gdi/salgdilayout.cxx:431 #8 0x0109f239 in OutputDevice::ImplDrawOutDevDirect (this=0x2fd5624, pSrcDev=0x2fd574c, pVoidPosAry=0xbfffe6a4) at /Users/pavel/BUILD/AQUA/BuildDir/ooo_SRC680_m195_src/vcl/source/ gdi/outdev2.cxx:287 #9 0x010a51cd in OutputDevice::DrawOutDev (this=0x2fd5624, rDestPt=@0xbfffe7f0, rDestSize=@0xbfffe800, rSrcPt=@0xbfffe7f8, rSrcSize=@0xbfffe808, rOutDev=@0x2fd574c) at /Users/ pavel/BUILD/AQUA/BuildDir/ooo_SRC680_m195_src/vcl/source/gdi/outdev2.cxx:433 #10 0x14ea0692 in desktop::SplashScreen::Paint () But nevertheless it is still connected with bitmap with splashscreen in this case. To reproduce: 1. compile complete VCL without debug: cd vcl; build Test application -> it works. 2. recompile everything with debug turned on: rm -rf unxmac*pro; build debug=t Application crashes. 3. touch aqua/source/gdi/salbmp.cxx cd aqua/source/gdi; dmake build debug=t Application starts.
Created attachment 41108 [details] command line from normal compilation
Created attachment 41109 [details] Command line from debug compilation
Command line differences: normal: -O2 -fno-strict-aliasing -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE debug: -g -O0 -DOSL_DEBUG_LEVEL=2 -DDEBUG
I'll verify, which particular change made it nonworking...
According to my tests: 1. if salbmp.cxx is compiled with -O0, it crashes. 2. if salbmp.cxx is compiled with -O2, it works. -O1 works as well. It is probably compiler bug 8)
@pjanik: I really can't do much about this, the code looks perfectly right. It might though be another place in that file, ttat causes the heap corruption...
thb: right. I'll investigate more. I suspect compiler bug. I'll try to prepare small testcase for it as well.
Setting keyword
Crashes on PPC as well: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0423264e 0x900034f4 in szone_malloc () (gdb) where #0 0x900034f4 in szone_malloc () #1 0x00000089 in ?? () #2 0x90003200 in szone_malloc () #3 0x94b66350 in operator new () #4 0x0147b62c in boost::detail::shared_count::shared_count<unsigned char*, boost::checked_array_deleter<unsigned char> > (this=0xbfffe3dc, p=0x0, d={<No data fields>}) at detail/shared_count.hpp:348 #5 0x0147b6dc in boost::shared_array<unsigned char>::shared_array (this=0xbfffe3d8, p=0x0) at shared_array.hpp:56 #6 0x0147b718 in boost::shared_array<unsigned char>::reset (this=0x4132610, p=0x0) at shared_array.hpp:75 #7 0x012fba48 in AquaSalBitmap::Destroy (this=0x4132600) at /Volumes/Build/oo/BUILD/AQUA/ BuildDir/ooo_SRC680_m201_src/vcl/aqua/source/gdi/salbmp.cxx:200 #8 0x012faca0 in AquaSalBitmap::AllocateUserData (this=0x4132600) at /Volumes/Build/oo/BUILD/ AQUA/BuildDir/ooo_SRC680_m201_src/vcl/aqua/source/gdi/salbmp.cxx:261 #9 0x012fb110 in AquaSalBitmap::Create (this=0x4132600, rSize=@0xbfffe6c8, nBits=8, rBitmapPalette=@0xbfffe6d0) at /Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/ vcl/aqua/source/gdi/salbmp.cxx:156 #10 0x0107fb5c in ImpBitmap::ImplCreate (this=0x4131520, rSize=@0xbfffe6c8, nBitCount=8, rPal=@0xbfffe6d0) at /Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/ gdi/impbmp.cxx:83 #11 0x01032728 in Bitmap::Bitmap (this=0xbfffe6d8, rSizePixel=@0xbfffe6c8, nBitCount=8, pPal=0xbfffe6d0) at /Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/ gdi/bitmap.cxx:180 #12 0x0103c198 in Bitmap::ImplReadDIB (rIStm=@0xbfffe8c8, rBmp=@0x37ec850, nOffset=1064) at / Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/gdi/bitmap2.cxx:192 #13 0x0103c678 in Bitmap::Read (this=0x37ec850, rIStm=@0xbfffe8c8, bFileHeader=1 '\001') at / Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/gdi/bitmap2.cxx:160 #14 0x0103c748 in operator>> (rIStm=@0xbfffe8c8, rBitmap=@0x37ec850) at /Volumes/Build/oo/ BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/gdi/bitmap2.cxx:134 #15 0x054642c8 in desktop::SplashScreen::findBitmap () #16 0x05464b48 in desktop::SplashScreen::initBitmap () #17 0x05464f68 in desktop::SplashScreen::initialize () #18 0x0246e1c0 in cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext (this=<value optimized out>, rArguments=@0xbfffede0, xContext=<value optimized out>) at / Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/cppuhelper/source/factory.cxx:256 #19 0x0246e47c in cppu::OFactoryComponentHelper::createInstanceWithArgumentsAndContext (this=0x5390714, rArguments=@0xbfffede0, xContext=@0x3730214) at /Volumes/Build/oo/BUILD/ AQUA/BuildDir/ooo_SRC680_m201_src/cppuhelper/source/factory.cxx:536 #20 0x0246f7e0 in cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext (this=0x53ec854, rArguments=@0xbfffede0, xContext=@0x3730214) at /Volumes/Build/oo/BUILD/ AQUA/BuildDir/ooo_SRC680_m201_src/cppuhelper/source/factory.cxx:841 #21 0x040185c0 in stoc_smgr::OServiceManager::createInstanceWithArgumentsAndContext () #22 0x0400c520 in stoc_smgr::OServiceManager::createInstanceWithArguments () #23 0x00014ad0 in ?? () #24 0x00015244 in ?? () #25 0x01021fec in ImplSVMain () at /Volumes/Build/oo/BUILD/AQUA/BuildDir/ ooo_SRC680_m201_src/vcl/source/app/svmain.cxx:254 #26 0x01022254 in MainRunLoopForThreadedApps (inTimer=0x41102f0, inUserData=0x0) at / Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/vcl/source/app/svmainhook.cxx:66 #27 0x907f0550 in __CFRunLoopDoTimer () #28 0x907dcec8 in __CFRunLoopRun () #29 0x907dc47c in CFRunLoopRunSpecific () #30 0x93208740 in RunCurrentEventLoopInMode () #31 0x93207dd4 in ReceiveNextEventCommon () #32 0x9324cee4 in AcquireNextEventInMode () #33 0x9324ccd4 in RunApplicationEventLoop () #34 0x0102233c in ImplSVMainHook (pbInit=0xbffff9b8 "") at /Volumes/Build/oo/BUILD/AQUA/ BuildDir/ooo_SRC680_m201_src/vcl/source/app/svmainhook.cxx:86 #35 0x010221c8 in SVMain () at /Volumes/Build/oo/BUILD/AQUA/BuildDir/ooo_SRC680_m201_src/ vcl/source/app/svmain.cxx:292 #36 0x000041f0 in ?? () #37 0x00002d6c in ?? () #38 0x00002a70 in ?? () (gdb)
Adding to Meta Issue.
It appears gcc has a problem with member templates. By forcing the use of the non-member-template using variant of the shared_array class (boost/detail/shared_array_nmt.hpp) the crash doesn't occur anymore when compiling with debug. Forcing to use the non-member template variant is accomplished by defining 'BOOST_NO_MEMBER_TEMPLATE' and undefining 'BOOST_MSVC6_MEMBER_TEMPLATES' at the beginning of shared_array.hpp (to test it use the *.hpp file delivered to solver/.../inc/boost/...!).
ericb->tra Confirmed. I did : 1) #undef BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_NO_MEMBER_TEMPLATE in solver//.../inc/boost/shared_array.hpp 2) "build debug=t" somewhere in vcl,n and I can launch soffice.bin without crash, with symbols inside. This would confirm the compiler bug, but I can be wrong.
tra->ericb: Not sure yet about the compiler bug. I couldn't reproduce the problem yet with a simple test program which makes me wonder. I will continue to investigate...
Tino is working on this issues.
.
set OS
ericb->fheckl Florian, could you please test in 10.5 the issue is or not fixed ? We would like to verify this is a gcc bug. Thank you :)
tra->ericb: I still bet that it is a memory overwrite lurking somewhere in the code. Hopefully I can prove that soon. :) But anyway testing it on Leopard doesn't hurt.
OK, I will give it a try on Leopard.
From my point of view it looks like the problem with VCL debug=t only happens when built with XCode<=2.4.0 and cannot be reproduced when compiled in an XCode 2.4.1 environment...
Ok, after a reaalllyy long debugging session I think I understand what happened: - SRC680_m211 uses the boost-1.30.2 headers - the boost header file "macosx.hpp" includes "posix_features.hpp" - unless TARGET_CARBON is defined, which we have for obvious reasons in the VCL aqua build - without "posix_features.hpp" boost doesn't know that the OS has pthread support - when boost doesn't know which threading library to use it undefines BOOST_HAS_THREADS - boost/detail/shared_count.hpp without BOOST_HAS_THREADS doesn't use pthread mutexes - so the class sp_counted_base does no longer contain a mutex member mtx_ => - this base class now has a different memory layout in VCL than other libraries => - a different memory layout of classes with the same name does not seem to be too much of a problem, when the class is only used inline - when inlining is disabled (e.g. for -O0 or also for -O -fno-default-inline) then the problem rears its ugly head very forcefully So even in a build without debug=true the problem was there, only much smaller. With objects of type shared_counter not being mutex protected the problem would have shown only for highly multithreaded use cases. Newer versions of boost's macos.hpp header file do not disable pthread mutexes for shared_counter (some related info can be found here: http://lists.boost.org/boost-users/2004/10/8110.php). We should either upgrade the boost library or patch our boost macos.hpp include file to remove the stupid TARGET_CARBON check.
ericb->hdu First thanks for your work ! Second : I think create a new patch for boost is simple, and won't bother other ports/archs. Of course, we will follow what you suggest.
@hdu: excellent work. I'll buy you a beer! Regarding boost: please patch the CARBON check out, updating boost needs a legel review, which takes time (but we could push that nevertheless, in parallel).
Thanks for the flowers :-) Now is also clear why some builds worked and some didn't: vcl/aqua had the TARGET_CARBON flag and the platform independent vcl didn't have it. salbmp.cxx in aqua and pdfextoutdevdata.cxx both used the boost functionality. So there were two different template instantiations of the boost::detail::shared_count. The linker removed one of the template instantiations and if the TARGET_CARBON object won => crash in salbmp.cxx, else vcl would have crashed later during PDF export
Please verify (update boost to cws_src680_aquavcl01, build, deliver, rebuild vcl)
issue Verified Fixed : no more crash when debug is enabled in libvcl.
The change works now perfectly in aquavcl01. To remove the changes from module boost from aquavcl01, I'll move the changes to pj81 and proceed with their integration after testing on X11. These changes will be autoremoved from aquavcl01 after resync.
Patch re-applied to pj81.
verified in pj81
Change target milestone to 2.3.
Still OK on SRC680_m220. Closing.