Re: URGENT: Need to build new version based on 4.1.4
I see you have checked in some Mac building changes. Would it be better to keep the two fixes separate, or encourage testing both of them together? On 11/18/2017 1:20 PM, Jim Jagielski wrote: We do have the AOO415 branch! :) On Nov 18, 2017, at 2:11 PM, Patricia Shanahanwrote: There is a bug in my LinkManager changes. Specifically, I made the totally newbie mistake of accessing memory based on a pointer without allowing for it being null, and it turns out it can be null :-( The primary report for this is https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after copying all content". I would have expected the failure to be some form of access violation. However, recent e-mails have convinced me that some paths include catch blocks that conceal all exceptions, so it may be the root cause of other problems. I have checked a fix into the trunk, revision 1814994. However, trunk has other changes. The simplest way to check whether other bug reports are due to this is to build a version that is identical to 4.1.4 except for the one fix. Anything that works with that but not with 4.1.4 is a duplicate. Of course, the more duplicates we have the worse the problem and the more urgent a fix. I am going ahead and doing the fix in my 4.1.5 working copy, but activating 4.1.5 is a broader decision. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: URGENT: Need to build new version based on 4.1.4
We do have the AOO415 branch! :) > On Nov 18, 2017, at 2:11 PM, Patricia Shanahanwrote: > > There is a bug in my LinkManager changes. Specifically, I made the totally > newbie mistake of accessing memory based on a pointer without allowing for it > being null, and it turns out it can be null :-( > > The primary report for this is > https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after > copying all content". > > I would have expected the failure to be some form of access violation. > However, recent e-mails have convinced me that some paths include catch > blocks that conceal all exceptions, so it may be the root cause of other > problems. > > I have checked a fix into the trunk, revision 1814994. However, trunk has > other changes. > > The simplest way to check whether other bug reports are due to this is to > build a version that is identical to 4.1.4 except for the one fix. Anything > that works with that but not with 4.1.4 is a duplicate. Of course, the more > duplicates we have the worse the problem and the more urgent a fix. > > I am going ahead and doing the fix in my 4.1.5 working copy, but activating > 4.1.5 is a broader decision. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: URGENT: Need to build new version based on 4.1.4
I'm attaching the patch in case anyone else wants to build their own test version. On 11/18/2017 11:11 AM, Patricia Shanahan wrote: There is a bug in my LinkManager changes. Specifically, I made the totally newbie mistake of accessing memory based on a pointer without allowing for it being null, and it turns out it can be null :-( The primary report for this is https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after copying all content". I would have expected the failure to be some form of access violation. However, recent e-mails have convinced me that some paths include catch blocks that conceal all exceptions, so it may be the root cause of other problems. I have checked a fix into the trunk, revision 1814994. However, trunk has other changes. The simplest way to check whether other bug reports are due to this is to build a version that is identical to 4.1.4 except for the one fix. Anything that works with that but not with 4.1.4 is a duplicate. Of course, the more duplicates we have the worse the problem and the more urgent a fix. I am going ahead and doing the fix in my 4.1.5 working copy, but activating 4.1.5 is a broader decision. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Index: main/sfx2/source/appl/linkmgr2.cxx === --- main/sfx2/source/appl/linkmgr2.cxx (revision 1813359) +++ main/sfx2/source/appl/linkmgr2.cxx (working copy) @@ -158,9 +158,13 @@ SvBaseLinkRef* pTmp = new SvBaseLinkRef( pLink ); pLink->SetLinkManager( this ); aLinkTbl.Insert( pTmp, aLinkTbl.Count() ); - Window *parent = GetPersist()->GetDialogParent(); if (mAutoAskUpdateAllLinks) { + Window *parent = NULL; + SfxObjectShell* persist = GetPersist(); + if (persist != NULL) + parent = GetPersist()->GetDialogParent(); + SetUserAllowsLinkUpdate(pLink, GetUserAllowsLinkUpdate(parent)); } - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
URGENT: Need to build new version based on 4.1.4
There is a bug in my LinkManager changes. Specifically, I made the totally newbie mistake of accessing memory based on a pointer without allowing for it being null, and it turns out it can be null :-( The primary report for this is https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after copying all content". I would have expected the failure to be some form of access violation. However, recent e-mails have convinced me that some paths include catch blocks that conceal all exceptions, so it may be the root cause of other problems. I have checked a fix into the trunk, revision 1814994. However, trunk has other changes. The simplest way to check whether other bug reports are due to this is to build a version that is identical to 4.1.4 except for the one fix. Anything that works with that but not with 4.1.4 is a duplicate. Of course, the more duplicates we have the worse the problem and the more urgent a fix. I am going ahead and doing the fix in my 4.1.5 working copy, but activating 4.1.5 is a broader decision. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FYI: The OO 4.1.4 Mac problem
Great! Another regression was just reported - https://bz.apache.org/ooo/show_bug.cgi?id=127600 I wonder if it is fixed too? Sent from my iPhone > On Nov 18, 2017, at 10:17 AM, Larry Gusaaswrote: > > Database and Spreadsheets both work. Regressions are fixed. I haven't done > any further testing yet. > > Larry > >> On 2017-11-18, 9:13 AM Jim Jagielski wrote: >> fingers-crossed... >> >> I have updated the files in devtools related to my successful build of AOO >> 4.1.4 >> for macOS that appears to fix both regressions. >> >> Basically: >> >> o I had to use Xcode7 on Sierra >> o I had to compile frameworks w/ -O1 instead of -O2 >> >> Uploads to our dev dist repo are happening as we speak. >> >> __ >> > > -- > > - > > Larry I. Gusaas > Moose Jaw, Saskatchewan Canada > Website: http://larry-gusaas.com > > “To me, photography is the simultaneous recognition, in a fraction of a > second, of the significance of an event as well as of a precise organization > of forms which give that event its proper expression.” Henri Cartier-Bresson > > "An artist is never ahead of his time but most people are far behind theirs." > - Edgard Varese > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org >
Re: FYI: The OO 4.1.4 Mac problem
Database and Spreadsheets both work. Regressions are fixed. I haven't done any further testing yet. Larry On 2017-11-18, 9:13 AM Jim Jagielski wrote: fingers-crossed... I have updated the files in devtools related to my successful build of AOO 4.1.4 for macOS that appears to fix both regressions. Basically: o I had to use Xcode7 on Sierra o I had to compile frameworks w/ -O1 instead of -O2 Uploads to our dev dist repo are happening as we speak. __ -- - Larry I. Gusaas Moose Jaw, Saskatchewan Canada Website: http://larry-gusaas.com “To me, photography is the simultaneous recognition, in a fraction of a second, of the significance of an event as well as of a precise organization of forms which give that event its proper expression.” Henri Cartier-Bresson "An artist is never ahead of his time but most people are far behind theirs." - Edgard Varese - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FYI: The OO 4.1.4 Mac problem
In the meantime, I need to figure out how to, in main/frameworks, have the gbuild system automatically change the -O2 to -O1 for MACOS... It's not CFLAGS or CXXFLAGS. There doesn't look to be a way to change gb_COMPILEROPTFLAGS and/or CFLAGSOPT via the gbuild eval->call functionality. > On Nov 18, 2017, at 10:13 AM, Jim Jagielskiwrote: > > fingers-crossed... > > I have updated the files in devtools related to my successful build of AOO > 4.1.4 > for macOS that appears to fix both regressions. > > Basically: > > o I had to use Xcode7 on Sierra > o I had to compile frameworks w/ -O1 instead of -O2 > > Uploads to our dev dist repo are happening as we speak. > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FYI: The OO 4.1.4 Mac problem
Hi Jim - Good news. I’m out of pocket until tomorrow evening. Perhaps Larry is available. Regards, Dave Sent from my iPhone > On Nov 18, 2017, at 7:43 AM, Matthias Seidel> wrote: > > Hi Jim, > > That would be great! > > Unfortunately I can't help with testing on macOS... > > Regards, Matthias > > >> Am 18.11.2017 um 16:13 schrieb Jim Jagielski: >> fingers-crossed... >> >> I have updated the files in devtools related to my successful build of AOO >> 4.1.4 >> for macOS that appears to fix both regressions. >> >> Basically: >> >> o I had to use Xcode7 on Sierra >> o I had to compile frameworks w/ -O1 instead of -O2 >> >> Uploads to our dev dist repo are happening as we speak. >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FYI: The OO 4.1.4 Mac problem
Hi Jim, That would be great! Unfortunately I can't help with testing on macOS... Regards, Matthias Am 18.11.2017 um 16:13 schrieb Jim Jagielski: > fingers-crossed... > > I have updated the files in devtools related to my successful build of AOO > 4.1.4 > for macOS that appears to fix both regressions. > > Basically: > > o I had to use Xcode7 on Sierra > o I had to compile frameworks w/ -O1 instead of -O2 > > Uploads to our dev dist repo are happening as we speak. > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: Debugging Base's "Create Table in Design View"
Yesterday, in the email thread entitled "FYI: The OO 4.1.4 Mac problem", Dave Fisher asked me for help with the problem where the "Create Table in Design View" does nothing on a Mac release. Was the problem fixed in the meanwhile? Is there another problem? What happened? Do you still need my help? Thank you Damjan On Sat, Nov 18, 2017 at 5:47 AM, Patricia Shanahanwrote: > Is it possible that this is another manifestation of > https://bz.apache.org/ooo/show_bug.cgi?id=127581 > > If so, it will not happen in the trunk. > > > On 11/17/2017 10:47 AM, Damjan Jovanovic wrote: > >> tl;dr: >> Put a breakpoint on dbaui::DatabaseObjectView::doDispatch or >> /full/path/to/main/dbaccess/source/ui/misc/databaseobjectview.cxx:120 >> just >> before you click the "Create Table..." button. >> Step through it in your debugger line by line and document how for you >> get. >> Then recursively repeat and step deeper and deeper into the last statement >> before the exception is thrown, until you narrow down the failure at its >> source. >> A debug build of main/dbaccess may also help ("build debug=true" in >> main/dbaccess). >> Email us back with your findings. >> >> The long version: >> -- >> >> Opening the "Create Table in Design View" dialog and attaching GDB and >> running "thread apply all bt" doesn't show anything useful, so we go >> through the source instead. >> >> The text "Create Table in Design View" must come from somewhere: >> >> [main/dbaccess]$ grep "Create Table in Design View" * -R >> source/ui/app/app.src:Text [ en-US ] = "Create Table in Design >> View..." >> ; >> >> Looking at that file we see: >> >> String RID_STR_NEW_TABLE >> { >> Text [ en-US ] = "Create Table in Design View..." ; >> }; >> >> Now look for RID_STR_NEW_TABLE: >> >> [main/dbaccess]$ grep RID_STR_NEW_TABLE * -R >> source/ui/app/app.src:String RID_STR_NEW_TABLE >> source/ui/app/app.src:String RID_STR_NEW_TABLE_AUTO >> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE >> RID_STR_APP_START + 4 >> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE_AUTO >> RID_STR_APP_START + 5 >> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry( >> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) >> ); >> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry( >> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD, >> RID_STR_NEW_TABLE_AUTO ) ); >> >> Only the source/ui/app/AppDetailView.cxx is useful, as it contains actual >> code. This is what it does: >> >> switch ( _eType ) >> { >> case E_TABLE: >> rList.push_back( TaskEntry( ".uno:DBNewTable", >> RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) ); >> rList.push_back( TaskEntry( ".uno:DBNewTableAutoPilot", >> RID_STR_TABLES_HELP_TEXT_WIZARD, RID_STR_NEW_TABLE_AUTO ) ); >> rList.push_back( TaskEntry( ".uno:DBNewView", >> RID_STR_VIEWS_HELP_TEXT_DESIGN, RID_STR_NEW_VIEW, true ) ); >> _rData.nTitleId = RID_STR_TABLES_CONTAINER; >> break; >> >> which doesn't help much. But it does link it to ".uno:DBNewTable". Where >> else is that used? >> >> [main/dbaccess]$ grep "\.uno:DBNewTable" * -R >> source/ui/control/toolboxcontroller.cxx: >> m_aStates.insert(TCommandState::value_type(::rtl::OUString( >> RTL_CONSTASCII_USTRINGPARAM(".uno:DBNewTable")) ,sal_True)); >> source/ui/app/AppController.cxx:implDescribeSupportedFeature( >> ".uno:DBNewTable", ID_NEW_TABLE_DESIGN, CommandGroup::INSERT >> ); >> source/ui/app/AppController.cxx:implDescribeSupportedFeature( >> ".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT, >> source/ui/app/app.src:Command = ".uno:DBNewTable"; >> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry( >> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) >> ); >> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry( >> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD, >> RID_STR_NEW_TABLE_AUTO ) ); >> uiconfig/dbapp/menubar/menubar.xml:> menu:id=".uno:DBNewTable"/> >> >> Here we have a number of matches. The menubar.xml is related to the GUI >> layout, we want the code. The app.src we've already looked at. That only >> leaves toolboxcontroller.cxx, AppController.cxx and AppDetailView.cxx. >> AppDetailView.cxx only uses ".uno:DBNewTable" for what we've already seen, >> to add it to rList. toolboxcontroller.cxx also only uses that string in >> some initialization code. So through a process of elimination, we're only >> left with AppController.cxx. >> >> It contains only 1 matching line: >> >> implDescribeSupportedFeature( ".uno:DBNewTable", >> ID_NEW_TABLE_DESIGN, CommandGroup::INSERT ); >> >> We continue on with this ID_NEW_TABLE_DESIGN: >> >> [main/dbaccess]$ grep ID_NEW_TABLE_DESIGN * -R >> source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN: >>
Re: Release 4.1.4
Hallo Josef, Am 24.10.2017 um 19:41 schrieb Josef Latt: > > > Am 24.10.2017 um 18:27 schrieb Matthias Seidel: >> >> Das war vielleicht bei 4.1.3 so, aber in 4.1.4 sind alle mir bekannten >> Probleme mit Ubuntu behoben. >> Es lag auch nie an Ubuntu (bzw. Gnome), es trat halt nur dort auf. Die >> Fehler waren in unserem Code. > > In der 17.04 hatte ich nichts mehr von Libreoffice auf dem Rechner. > AOO-Dateien wurden im Nautilus mit dem Standardtext-Icon angezeigt. > Nach dem Upgrade auf die 17.10 (Gnome) waren die Libreoffice-Icons > wieder auf dem Rechner. Libreoffice dagegen selbst nicht. Also war > wiederum händisches Löschen angesagt -> Standardtext-Icons. Ich vermute weiterhin, dass unser Script für die Desktop-Integration irgendwie nicht greift. Denn statt der Standard-Icons sollten die von OpenOffice angezeigt werden (auch ohne löschen der zwangsgebündelten LO-Icons). > > Noch was: Ich starte AOO immer über das Startcenter, das als Favorit > abgelegt ist, mit dem Effekt, dass ein zweites Icon unten in der > Favoritenleiste erscheint. Öffne ich nun z.B. eine Calc-Datei wird > selbiges durch das entsprechende Icon ersetzt. Das Öffnen weiterer > Dateien (Writer usw.) wird durch die entsprechende Anzahl roter Punkte > neben dem Calc-Icon angezeigt. Das Löschen der Calc-Datei ändert das > Icon nichts, bleibt Calc. > Das zusätzliche Icon entspricht immer dem Icon der zuerst geöffneten > Datei, sofern man zuvor nicht alle Dateien geschlossen hat. > > Mit dem Eintrag 'StartupWMClass=OpenOffice 4.1.4' (ohne > Anführungszeichen) in die Startcenter Desktop-Datei gibt es beim > Öffnen von Dateien kein zusätzliches Icon mehr. Anzahl der geöffneten > Dateien -> rote Punkte neben dem Startcenter-Icon. Komme jetzt erst dazu es unter 17.10 zu testen. Guter Tipp, funktioniert einwandfrei! Gruß, Matthias > > Gruß > Josef > > > > - > To unsubscribe, e-mail: dev-de-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-de-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: FYI: The OO 4.1.4 Mac problem
fingers-crossed... I have updated the files in devtools related to my successful build of AOO 4.1.4 for macOS that appears to fix both regressions. Basically: o I had to use Xcode7 on Sierra o I had to compile frameworks w/ -O1 instead of -O2 Uploads to our dev dist repo are happening as we speak. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Simpler Windows builds, oowintool, and Cygwin64
Hi John, Am 16.11.2017 um 11:48 schrieb John D'Orazio: > On Wed, Nov 15, 2017 at 6:17 PM, Matthias Seidel> wrote: >> I just updated config.guess and config.sub to the latest version. >> >> See: https://www.gnu.org/software/gettext/manual/html_node/ >> config_002eguess.html >> >> Regards, Matthias >> > Just wondering if after this update the configure script still runs fine? > About a year or so ago when I was testing a cygwin x64 build process, I > noticed that after updating config.guess and config.sub in the cygwin > terminal the configure script starting choking on config.sub. Were you able > to get past this? Seems we ran into the same error messages... ;-) I can confirm that the recently updated config.guess/config.sub do not break the build and error messages are gone. However it doesn't build with Cygwin64 because it detects "x86_64-unknown-cygwin" I will try "--build=i686-pc-cygwin" now. > > Unfortunately I don't have my system set up to build ATM, unfortunately my > "powerful" HP laptop comes with a miserly 128GB SSD as the main drive and > Visual Studio can't be installed on a secondary drive... I'm having a heck > of a time finding a bigger compatible SSD but I hope to resolve this soon, > and set up my build system again... My laptop was low on disk space too. But I could add an additional SSD in a PCIe slot... ;-) I run Ubuntu 16.04.3 with Windows 10 in VirtualBox. > As these obstacles are removed the Step by step guide can be updated, I had > opened a section about building with cywgwin x64 and I started jotting > provisional notes down, I'd say this looks like the time to update them: > https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Testing_build_with_Cygwin_64_bit > . I will update the Wiki step by step now. Regards, Matthias smime.p7s Description: S/MIME Cryptographic Signature