Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Jul 18, 2005 8:46 pm Post subject:
Nifty. I'll await them I think I'll go through and visually inspect them. If so, I'll try and isolate the 1.1.4 specific fixes for the NeoJ patch files If I remember, I'll post some instructions for how to generate a patch for the NeoJ against an OOo module that has OOo build dependencies like this issue.
Nifty. I'll await them I think I'll go through and visually inspect them. If so, I'll try and isolate the 1.1.4 specific fixes for the NeoJ patch files If I remember, I'll post some instructions for how to generate a patch for the NeoJ against an OOo module that has OOo build dependencies like this issue.
Great. BTW, I just finished building Neo/J on Tiger with the 1.1.5rc code. I was not ready for the enormous helpfile download which delayed building for almost a day.
In any case, I think that I will get the code back to Patrick and you for a bunch of testing. I just need a place to put it.
Great. BTW, I just finished building Neo/J on Tiger with the 1.1.5rc code. I was not ready for the enormous helpfile download which delayed building for almost a day.
In any case, I think that I will get the code back to Patrick and you for a bunch of testing. I just need a place to put it.
Since your code changes only affect OOo, I would recommend that you give this code directly back to the OOo team first so that it has a reasonable chance of being included in the OOo CVS tree. The easiest way to do this is to do the following:
1. Open a new issue in OOo's Bugzilla and cc: ericb and pluby and whomever else you think might be working on OOo 1.1.5 for Mac OS X.
2. Create a "cvs diff -u" attachment for each module that you changed and attach the diff to the issue. Note: I suggest that you use the following command in a bash shell to strip out stderr from the diff file:
cd <module> ; cvs diff -u 2>/dev/null >../<module>.diff
By creating such an issue, the code will not get lost and if, for some reason, you code doesn't get integrated into the OOo CVS tree, I can easily grab your patches when I am ready to deal with the OOo 1.1.5 code.
Great. BTW, I just finished building Neo/J on Tiger with the 1.1.5rc code. I was not ready for the enormous helpfile download which delayed building for almost a day.
In any case, I think that I will get the code back to Patrick and you for a bunch of testing. I just need a place to put it.
Since your code changes only affect OOo, I would recommend that you give this code directly back to the OOo team first so that it has a reasonable chance of being included in the OOo CVS tree. The easiest way to do this is to do the following:
1. Open a new issue in OOo's Bugzilla and cc: ericb and pluby and whomever else you think might be working on OOo 1.1.5 for Mac OS X.
This I can do.
[quote="pluby']
2. Create a "cvs diff -u" attachment for each module that you changed and attach the diff to the issue. Note: I suggest that you use the following command in a bash shell to strip out stderr from the diff file:
cd <module> ; cvs diff -u 2>/dev/null >../<module>.diff
By creating such an issue, the code will not get lost and if, for some reason, you code doesn't get integrated into the OOo CVS tree, I can easily grab your patches when I am ready to deal with the OOo 1.1.5 code.
[/quote]
This I cannot as I have not signed the JCA and may not be able to due to a NDA that I have signed with my employer.
This I cannot as I have not signed the JCA and may not be able to due to a NDA that I have signed with my employer.
Huh? The key thing is whether you or your employer owns the code you have written. If you did it on your own time and with your own equipment, I really don't see how your employer can claim ownership of the code. If you own the code, then the JCA should be signable because it only applies to code that you own and contribute to OOo.
If, for some strange reason, your employer owns the code and is subject to their NDA, then you cannot give I or Ed the code either because 1) you would be disclosing the code and 2) we cannot use it because you can't license something that you don't own.
This I cannot as I have not signed the JCA and may not be able to due to a NDA that I have signed with my employer.
Huh? The key thing is whether you or your employer owns the code you have written. If you did it on your own time and with your own equipment, I really don't see how your employer can claim ownership of the code. If you own the code, then the JCA should be signable because it only applies to code that you own and contribute to OOo.
If, for some strange reason, your employer owns the code and is subject to their NDA, then you cannot give I or Ed the code either because 1) you would be disclosing the code and 2) we cannot use it because you can't license something that you don't own.
You have a very valid point at the end, Patrick. That is why I'm going to talk to my boss and see what she has to say.
If you checked out the HEAD branch of the Neo/J CVS repository, you will get the Java 1.4 work that I am doing. Since I am doing a blizzard of commits each day, who knows what you will get at any moment. Also, even if it builds and installs, it will be flaky since it is very early in development.
So, if you want the Neo/J 1.1 sources, you should check out Neo/J with the "NeoOfficeJ-1_1" tag (as per the build instructions on the Neo/J website).
If you checked out the HEAD branch of the Neo/J CVS repository, you will get the Java 1.4 work that I am doing. Since I am doing a blizzard of commits each day, who knows what you will get at any moment. Also, even if it builds and installs, it will be flaky since it is very early in development.
So, if you want the Neo/J 1.1 sources, you should check out Neo/J with the "NeoOfficeJ-1_1" tag (as per the build instructions on the Neo/J website).
That is what I thought was going on. Just for information, what are you using as a build platform (OS version, Java version)?
And I'll stay away from HEAD for a while, unless you want a second build tester, and get the Neo-1.1 tag. Has there been any patches after Patch 0?
That is what I thought was going on. Just for information, what are you using as a build platform (OS version, Java version)?
Panther with Java 1.4.1. Note: OOo always needs Java 1.4.x or higher to build even though Neo/J used Java 1.3.1 at runtime.
jjmckenzie51 wrote:
And I'll stay away from HEAD for a while, unless you want a second build tester, and get the Neo-1.1 tag. Has there been any patches after Patch 0?
Correction: check out "NeoOfficeJ-1_1_branch". This branch tag is "NeoOfficeJ-1_1" plus the "Patch-0" changes. Other than the "Patch-0" changes, there have been no other changes in this branch.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 10:47 am Post subject:
I believe I may have tracked down the potential source of the memory corruption and idlc crash...the problem is in the 10.3 and higher code within sal/systools/macxp_extras/x11osx/osxlocale.c. Note that whomever wrote the locale code is changing the code based upon the build machine OS rather than the runtime. This Panther + up locale code therefore hasn't been tested since we've been building NeoJ on 10.2, and all of my previous work from 10.3 was based off of a 10.2 initial build of the sal module within OOo. Here's the problem...
If you look, there is a call to CFRelease() of both the CFLocaleRef and the CFStringRef that is gotten from CFLocaleGetIdentifier(). However, if you look at the actual developer reference page for CFLocaleGetIdentifier():
You should notice that it explicitly says "retain and release as necessary". Since the locale code never retains this object and we just use the reference within the scope, underlying ownership remains with the localeref object. The CFRelease() on that string is a double free.
In the case of idlc, this was causing an objecive C message to be sent to a bad object. Fixing the double-free has resolved the idlc crash on my 10.4.2/XCode 2.1 build of HEAD. I'll work on developing a sal patch and putting it on HEAD and let the compilation commence!
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 11:02 am Post subject:
The sal module fixes for builds on 10.3 machines and up are committed to NeoJ CVS on the HEAD branch. I tested proper application of the patch to the OOo checkout via the NeoJ makefile.
BTW, we also have not seen this bug in Neo/J at runtime because in Neo/J, all of that code is replaced with code that looks up the locale from the applciation bundle.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 11:32 am Post subject:
Good to know. I haven't seen any manifestations of it beyond the idlc crash, the strange memory corruption in rscdep, and the eventual failure of the command line installer/packager (OOo) that's run as part of the build process. I'm hoping it'll tag all of those issues, but it'll take me a whiel to find out as I'm compiling on a slow machine
I also switched the memory allocator back to the stock OOo allocator as I surmise this was the double memory free that was confusing it previously (but not the system allocator).
BTW, we also have not seen this bug in Neo/J at runtime because in Neo/J, all of that code is replaced with code that looks up the locale from the applciation bundle.[/quote}
Maybe that is what fixed my build and stopped the idlc crash when building udkapi and why I did not get rspdsp build error.
Right now, I'm building HEAD and that might prove interesting.
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 think I'll go through and visually inspect them. If so, I'll try and isolate the 1.1.4 specific fixes for the NeoJ patch files 
