Issue 72248 - vcl compiled with debug crashes
Summary: vcl compiled with debug crashes
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: 680m193
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: tino.rachui
QA Contact: issues@porting
URL:
Keywords: aqua
Depends on:
Blocks: 74396
  Show dependency tree
 
Reported: 2006-12-04 11:05 UTC by pavel
Modified: 2007-07-09 22:02 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
command line from normal compilation (5.82 KB, text/plain)
2006-12-04 11:44 UTC, pavel
no flags Details
Command line from debug compilation (5.80 KB, text/plain)
2006-12-04 11:44 UTC, pavel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description pavel 2006-12-04 11:05:12 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.
Comment 1 pavel 2006-12-04 11:44:29 UTC
Created attachment 41108 [details]
command line from normal compilation
Comment 2 pavel 2006-12-04 11:44:51 UTC
Created attachment 41109 [details]
Command line from debug compilation
Comment 3 pavel 2006-12-04 11:47:03 UTC
Command line differences:

normal:      -O2    -fno-strict-aliasing -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE
debug:  -g -O0                                    -DOSL_DEBUG_LEVEL=2                    -DDEBUG
Comment 4 pavel 2006-12-04 11:47:28 UTC
I'll verify, which particular change made it nonworking...
Comment 5 pavel 2006-12-04 12:06:06 UTC
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)
Comment 6 thb 2007-01-11 14:52:15 UTC
@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...
Comment 7 pavel 2007-01-11 15:00:56 UTC
thb: right.

I'll investigate more. I suspect compiler bug. I'll try to prepare small testcase for it as well.
Comment 8 eric.bachard 2007-01-22 11:44:06 UTC
Setting keyword
Comment 9 pavel 2007-01-28 21:08:58 UTC
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) 
Comment 10 shaunmcdonald131 2007-02-10 10:36:27 UTC
Adding to Meta Issue.
Comment 11 tino.rachui 2007-02-18 21:50:43 UTC
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/...!).
Comment 12 eric.bachard 2007-02-20 16:58:35 UTC
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.



Comment 13 tino.rachui 2007-02-20 17:05:24 UTC
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...
Comment 14 pavel 2007-02-24 09:39:10 UTC
Tino is working on this issues.
Comment 15 pavel 2007-02-24 15:17:06 UTC
.
Comment 16 tino.rachui 2007-03-16 21:36:03 UTC
set OS
Comment 17 eric.bachard 2007-04-02 09:19:08 UTC
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 :)
Comment 18 tino.rachui 2007-04-03 20:48:18 UTC
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.
Comment 19 florian 2007-04-11 22:17:54 UTC
OK, I will give it a try on Leopard.
Comment 20 hdu@apache.org 2007-05-29 11:32:54 UTC
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...
Comment 21 hdu@apache.org 2007-06-01 16:38:56 UTC
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.
Comment 22 eric.bachard 2007-06-02 13:08:37 UTC
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.
Comment 23 thb 2007-06-02 23:09:32 UTC
@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).
Comment 24 hdu@apache.org 2007-06-04 10:04:48 UTC
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
Comment 25 hdu@apache.org 2007-06-04 10:06:49 UTC
Please verify (update boost to cws_src680_aquavcl01, build, deliver, rebuild vcl)
Comment 26 eric.bachard 2007-06-05 08:30:18 UTC
issue Verified Fixed :  no more crash when debug is enabled in libvcl.
Comment 27 pavel 2007-06-10 14:20:04 UTC
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.
Comment 28 pavel 2007-06-10 14:24:21 UTC
Patch re-applied to pj81.
Comment 29 lohmaier 2007-06-18 00:59:38 UTC
verified in pj81
Comment 30 pavel 2007-06-28 06:58:21 UTC
Change target milestone to 2.3.
Comment 31 pavel 2007-07-09 22:02:54 UTC
Still OK on SRC680_m220.

Closing.