Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jun 30, 2005 12:48 am Post subject:
(apologies I'm using this as my scratchpad so I don't forget what I'm finding when so tired)
Hmm...inbetween that second breakpoint hit and the allocation of the DirEntry, rtl_allocateMemory is not being called. It seems as if there's conflicting definitions of operator new() or something since the new calls in that line aren't hitting the breakpoints in sal/cpprt/operators_new_delete.cxx since that operator new() definition would result in mapping new to the rtl allocators. WTF?
Just an update...I still have been absolutely unable to track this biatch down. The system memory allocator is where the memory overwrite is occurring. The crash happens when rscdep is attempting to parse a path of the form "../..", e.g. pushing two "parent" entries onto the directory path stack. In between the two breakpoints at these directory puses, there is no call to system free, so my double free theory is out the window:
Code:
[206-72-79-245:wizards/source/formwizard] peterlin% gdb /Volumes/abyss/neoj11/neojava/build/solver/645/unxmacxp.pro/bin/rscdep
GNU gdb 6.1-20040303 (Apple version gdb-384) (Mon Mar 21 00:05:26 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ........ done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004b441
0x01031abc in CBlock::Insert (this=0x160eed0, p=0x160eeb0, nIndex=60688, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:266
266 pNodes[nIndex] = p;
(gdb) b dirent.cxx:2531
Breakpoint 1 at 0x105bb98: file /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx, line 2531.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Volumes/abyss/neoj11/neojava/build/solver/645/unxmacxp.pro/bin/rscdep -CHARSET_DONTKNOW -s -I. -I -I../inc -I../../inc -I../../unxmacxp.pro/inc -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" -fp../../unxmacxp.pro/srs/dbwizres.srs dbwizres.src
nlsupport.c: _imp_getProcessLocale() returning en_US.UTF-8 as current locale.
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2531
2531 if ( ( aStack.Count() == 0 ) ||
(gdb) n
2534 aStack.Push( new DirEntry( ByteString(), FSYS_FLAG_PARENT, eStyle ) );
(gdb)
2562 aPfad.Erase( 0, nPos + 1 );
(gdb) b free
[0] cancel
[1] all
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2531
2531 if ( ( aStack.Count() == 0 ) ||
(gdb)
Continuing.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004b441
0x01031abc in CBlock::Insert (this=0x160eed0, p=0x160eeb0, nIndex=60688, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:266
266 pNodes[nIndex] = p;
Thoughts? I'm also debugging with a sal that has debug symbols. I still can't track down where operator new is.
Only thing that is now coming to mind is that perhaps the -lstdc++ that's on all of the link lines for building on tiger is pulling in "libstdc++.dylib" instead of the gcc3.3 static C++ runtime library perhaps?
Interesting. The build of SRX645_m56 with a few patches just finished. I will look for this error when I run it. I ran into a problem with vcl and Xinerama which Patrick's patch for the util/makefile.mk fixed and a dependency problem between odfilter and xmloff which I put in as an issue. Other than this, the X11 build seems to have completed.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jul 01, 2005 6:05 pm Post subject:
I wound up scrapping my build and am going to start again on my 10.4 machine. I may have screwed up some settings as I was tweaking them during the build so will see if things will go cleanly.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Jul 02, 2005 6:02 pm Post subject:
FWIW, if I recompile sal with FORCE_SYSALLOC defined (so we use regular malloc/realloc/free instead of the custom OOo memory allocator) the crash goes away. There's some type of memory corruption going on but I'm not sure what...
Solutions seem to be to:
1) Use system memory allocator. I personally have no problem with this as I hate the idea of custom memory allocators on a fundamental level...
2) Debug further to find out what is causing the stomping. I also see ICU has a separate allocator mechanism but am unsure if it's used for ByteString. After some minor refactoring, it is the operator new() for DirEntry that is causing the crash, not the ByteString.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Jul 02, 2005 6:39 pm Post subject:
Note: Flagging DEBUG and setting OSL_DEBUG_LEVEL to 2 does not cause any double free or leak messages to be printed by the rtl allocator. It doesn't seem to be a logic failure in the rscdep or dirent code, but rather a failure in the allocator itself.
In the meantime I'm going to disable the custom memory allocator by adding a #define FORCE_SYSALLOC at the top of alloc.c so my build can continue. Using the memory allocator from OOoCVS HEAD also doesn't help, and no memory corruption messages are printed.
I've already spent two weeks debugging this garbage, so my recommendation is to scrap the OOo memory allocator and use the system allocator. The system malloc should also print out debugging messages for us on OS X, so I don't think it's a major loss.
If Patrick concurs, I'll flip the allocator in Neo CVS. In the meantime, you can just add the sysalloc define to your envcdefs or in alloc.c directly to continue.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 03, 2005 8:27 pm Post subject:
Well, the good news is that the compile finishes successfully with the system memory allocator, but the building of the install package is failing when one of the components (libdbu645xp.dylib) is being registered. I'm just hoping it's not a manifestation of a more insidious bug that just happened to be skipped by using the system memory allocator.
So it's off to figuring out what commands are being issued and trying to get a debugger on the register process to see why it's failing. Sigh.
So I've been trying to compile NeoOffice/J for Tiger 10.4 on and off for the past few weeks. I first experienced a segfault in the rscdep utility, so I decided to try to compile with debug symbols on (I edited the makefile to read "OO_BUILD_ARGS:=-u debug=true").
Now, when I recompile the build fails during the following command:
Code:
=============
Building project XmlSearch
=============
/Users/joecrow/prog/NeoOfficeSource/neojava/build/XmlSearch/src/com/sun/xmlsearch
Making dpj...
touch /Users/joecrow/prog/NeoOfficeSource/neojava/build/solver/645/unxmacxp.pro/inc/minormkchanged.flg
------------------------------
Making: ../../../../unxmacxp.pro/misc/com_sun_xmlsearch.dpc
dmake subdmake=true -u -f makefile.mk debug="true" depend=t ALLDPC
------------------------------
No Dependencies
javamaker -BUCR -O../../../../unxmacxp.pro/misc/java db.Block /Users/joecrow/prog/NeoOfficeSource/neojava/build/solver/645/unxmacxp.pro/bin/types.rdb
nlsupport.c: _imp_getProcessLocale() returning en_US.UTF-8 as current locale.
javamaker : init registries failed, check your registry files.
dmake: Error code 99, while making 'db/Block.java'
---* TG_SLO.MK *---
ERROR: Error 65280 occurred while making /Users/joecrow/prog/NeoOfficeSource/neojava/build/XmlSearch/src/com/sun/xmlsearch
make: *** [build.oo_all] Error 1
I have had tried to delete everything and start from scratch, but the build fails on the same error. The NeoOffice build process is fairly complicated and I'm having some trouble figuring out what the problem is. Does anyone have any ideas?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Jul 05, 2005 12:21 am Post subject:
The complicated part of the build process isn't actually from Patrick...it's all the cruft that's inherited from OpenOffice.org (which has a really really whacked out build process).
The failure you're experiencing is in one of the OpenOffice.org build tools. Several tools are built as binaries as part of the build procedure that are custom to OOo (e.g. rscdep, dmake, regsister, etc.) javamaker is another one of those custom build tools that's part of the OOo build procedure, and that's where it's crashing.
Unfortunately, I haven't seen that particular failure myself. Your best bet is to rebuild javamaker with debug symbols and then try debugging it to see what failed. Take a look at the gdb logs I have above to figure out how to get a crack at it.
Also, are you building with the OOo memory allocator or with the system memory allocator? You may want to try flipping allocators.
Since it's griping about its registry (and I'm having problems with the UNO registry during command line installation) it wouldn't surprise me if they're two manifestations of the same problem. This is the first time I've done a build with gcc 3.3; that may be an issue in addition to the 10.4 issues.
Here is something interesting. I decided to build one of the later milestone releases leading up to a possible release of 1.1.5, m56. I patched the code with some patches that had not been incoorporated into this release and I got an actual running version. Unfortunately, I blew away this install and now I can build, but cannot run the milestone build. I decided to CVS retrieve the next milestone and found that idlc again would not work. However, I patched an earlier module, sal, and idlc WOULD work as designed with Patrick's backcode to the OOo project. I will continue to work on this and maybe we are a step closer to a next release of OOo 1.1 and it will make working in Neo/J easier.
BTW, with the assistance of Maho's build perl scripts, I have build several working versions of OOo 1.9. The lastest milestone built was m112. Maho continues to work on the locale issue (I use the English build so I am unfortunately not able to test this problem.)
I continue to plug at this problem and may go back to the 1.1.4 release code and see if I can get a good build past the original idlc problem with the patches I found for sal.
James
Here is something interesting. I decided to build one of the later milestone releases leading up to a possible release of 1.1.5, m56. [...]
I continue to plug at this problem and may go back to the 1.1.4 release code and see if I can get a good build past the original idlc problem with the patches I found for sal.
James
So we're one step closer to native filepickers? (I believe us convincing you to take a look at that was what started this quixotic endeavour.... )
Thanks for continuing to slog through!
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jul 07, 2005 11:18 pm Post subject:
FWIW the culprit is not the memory allocator. The same tools that ran just fine on my cube would bus error on my tibook. I'm going to rebuild with the regular memory allocator again and unfortunately have to slog through and see just what the heck is different.
My latest theory is that by builidng on 10.4 we're linking to a newer version of libSystem. Perhaps mmap() has different behaviour then previous? Also I still am not ruling out gcc 3.3 since I've never used it for any of my builds before.
This is really a bizarre problem since there's no good candidate I can think of besides either a subtle compiler difference or the memory allocator. Running on the tibook though seems to indicate it's not the memory allocator that's at fault and it's some other memory corruption bug that I can't pick out with either gdb or the built in memory debugging of that OOo memory allocator. This sucks (and is not fun).
FWIW the culprit is not the memory allocator. The same tools that ran just fine on my cube would bus error on my tibook. I'm going to rebuild with the regular memory allocator again and unfortunately have to slog through and see just what the heck is different.
My latest theory is that by builidng on 10.4 we're linking to a newer version of libSystem. Perhaps mmap() has different behaviour then previous? Also I still am not ruling out gcc 3.3 since I've never used it for any of my builds before.
This is really a bizarre problem since there's no good candidate I can think of besides either a subtle compiler difference or the memory allocator. Running on the tibook though seems to indicate it's not the memory allocator that's at fault and it's some other memory corruption bug that I can't pick out with either gdb or the built in memory debugging of that OOo memory allocator. This sucks (and is not fun).
Ed:
I don't think the problem is with gcc 3.3 as the build goes along just fine. I've even seen code segments for (gasp!) 4.0 which tends to barf up on the c++ code used due to 'friendly' declarations.
Also, I sent you a message with the crashlog on what happened with the SRX645_m57 build. I actually have crashlogs that go back to the previous installs that failed, too. They all (strangely) look the same.
I could start a thread here, but I don't want to have this information in too many places (I opened an IZ at openoffice for this too.)
FWIW the culprit is not the memory allocator. The same tools that ran just fine on my cube would bus error on my tibook. I'm going to rebuild with the regular memory allocator again and unfortunately have to slog through and see just what the heck is different.
My latest theory is that by builidng on 10.4 we're linking to a newer version of libSystem. Perhaps mmap() has different behaviour then previous? Also I still am not ruling out gcc 3.3 since I've never used it for any of my builds before.
This is really a bizarre problem since there's no good candidate I can think of besides either a subtle compiler difference or the memory allocator. Running on the tibook though seems to indicate it's not the memory allocator that's at fault and it's some other memory corruption bug that I can't pick out with either gdb or the built in memory debugging of that OOo memory allocator. This sucks (and is not fun).
Ed:
I don't think the problem is with gcc 3.3 as the build goes along just fine. I've even seen code segments for (gasp!) 4.0 which tends to barf up on the c++ code used due to 'friendly' declarations.
Also, I sent you a message with the crashlog on what happened with the SRX645_m57 build. I actually have crashlogs that go back to the previous installs that failed, too. They all (strangely) look the same.
I could start a thread here, but I don't want to have this information in too many places (I opened an IZ at openoffice for this too.)
James
[/quote]
Just as a note: I just built 645 milestone 56 using a large combination of patches, most of them are Patrick and Ed's. The patch file is over 600K in size. I am going to sed the file to remove the build directory and the control directory from the patch file. I don't have a location to put the patch file up for peer review. Is there one that I could put it at?
BTW, I have not signed Sun's JCA due to possible legal problems which were created by my current employer.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
(I believe us convincing you to take a look at that was what started this quixotic endeavour.... 
)