Re: Debugging Base's "Create Table in Design View"

2017-11-17 Thread Patricia Shanahan 
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:

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:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN:
source/ui/app/AppController.cxx: case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN:
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:MID_NEW_TABLE_DESIGN

Re: Debugging Base's "Create Table in Design View"

2017-11-17 Thread Damjan Jovanovic 
I've managed to trace it a bit further. The earlier loadComponentFromURL()
goes through main/framework and goes back into
main/dbaccess/source/ui/browser/dbloader.cxx, where DBContentLoader::load()
attempts to create a UNO component. This then goes into main/stoc but I
haven't been able to step into it further than
stoc_smgr::OServiceManager::createInstanceWithContext, which I think goes
into code compiled without debug information. Maybe I'll think of something
later.

I don't have any further suggestions for you on Mac at this point.

#0  stoc_smgr::OServiceManager::createInstanceWithContext
(this=0x77e84018, rServiceSpecifier=..., xContext=...) at
/AOO/main/stoc/source/servicemanager/servicemanager.cxx:1246
#1  0x7fffcc53cde8 in
comphelper::ComponentContext::createComponent
(this=this@entry=0x7fff9f20, _rServiceName=..., _out_rxComponent=...)
at /AOO/main/solver/420/unxlngx6/inc/comphelper/componentcontext.hxx:92
#2  0x7fffcc53ce89 in
comphelper::ComponentContext::createComponent
(this=this@entry=0x7fff9f20, _pAsciiServiceName=,
_out_rxComponent=...)
at /AOO/main/solver/420/unxlngx6/inc/comphelper/componentcontext.hxx:106
#3  0x7fffcc53b146 in DBContentLoader::load (this=0x7fffb40bb408,
rFrame=..., rURL=..., rArgs=..., rListener=...) at
/AOO/main/dbaccess/source/ui/browser/dbloader.cxx:219
#4  0x7fffda96c4e1 in framework::LoadEnv::impl_loadContent
(this=this@entry=0x7fffa248) at
/AOO/main/framework/source/loadenv/loadenv.cxx:1198
#5  0x7fffda96c8e5 in framework::LoadEnv::startLoading
(this=this@entry=0x7fffa248)
at /AOO/main/framework/source/loadenv/loadenv.cxx:433
#6  0x7fffda96ca04 in framework::LoadEnv::loadComponentFromURL
(xLoader=..., xSMGR=..., sURL=..., sTarget=..., nFlags=nFlags@entry=0,
lArgs=...) at /AOO/main/framework/source/loadenv/loadenv.cxx:205
#7  0x7fffda991bc4 in framework::Frame::loadComponentFromURL
(this=, sURL=..., sTargetFrameName=..., nSearchFlags=0,
lArguments=...) at /AOO/main/framework/source/services/frame.cxx:366
#8  0x7fffcc634fba in dbaui::DatabaseObjectView::doDispatch
(this=this@entry=0x7fffade0b6a0, i_rDispatchArgs=...) at
/AOO/main/dbaccess/source/ui/misc/databaseobjectview.cxx:155
#9  0x7fffcc63543c in dbaui::DatabaseObjectView::doCreateView
(this=this@entry=0x7fffade0b6a0, _rDataSource=..., _rObjectName=...,
i_rCreationArgs=...) at
/AOO/main/dbaccess/source/ui/misc/databaseobjectview.cxx:115
#10 0x7fffcc635513 in dbaui::TableDesigner::doCreateView
(this=this@entry=0x7fffade0b6a0, _rDataSource=..., _rObjectName=...,
i_rCreationArgs=...) at
/AOO/main/dbaccess/source/ui/misc/databaseobjectview.cxx:258
#11 0x7fffcc634785 in dbaui::DatabaseObjectView::createNew
(this=0x7fffade0b6a0, _xDataSource=..., i_rDispatchArgs=...) at
/AOO/main/dbaccess/source/ui/misc/databaseobjectview.cxx:95
#12 0x7fffcc4eb65b in dbaui::OApplicationController::newElement
(this=this@entry=0x7fffd801e220, _eType=_eType@entry=dbaui::E_TABLE,
i_rAdditionalArguments=..., o_rDocumentDefinition=...)
at /AOO/main/dbaccess/source/ui/app/AppController.cxx:2032
#13 0x7fffcc4f92cb in dbaui::OApplicationController::Execute
(this=0x7fffd801e220, _nId=, aArgs=...) at
/AOO/main/dbaccess/source/ui/app/AppController.cxx:1278
#14 0x7fffcc54fa15 in dbaui::OGenericUnoController::executeChecked
(this=0x7fffd801e220, _rCommand=..., aArgs=...) at
/AOO/main/dbaccess/source/ui/browser/genericcontroller.cxx:1270
#15 0x7fffcc517324 in dbaui::OCreationList::onSelected (this=, _pEntry=) at
/AOO/main/dbaccess/source/ui/app/AppDetailView.cxx:364
#16 0x731015ca in ImplHandleMouseEvent
(pWindow=pWindow@entry=0x7fffd9c8f320,
nSVEvent=nSVEvent@entry=2, bMouseLeave=bMouseLeave@entry=0 '\000',
nX=, nY=, nMsgTime=, nCode=1,
nMode=)
at /AOO/main/vcl/source/window/winproc.cxx:813
#17 0x7310250d in ImplHandleSalMouseButtonUp
(pWindow=pWindow@entry=0x7fffd9c8f320,
pEvent=) at /AOO/main/vcl/source/window/winproc.cxx:2086
#18 0x73101f00 in ImplWindowFrameProc (pWindow=0x7fffd9c8f320,
nEvent=, pEvent=0x7fffade8) at
/AOO/main/vcl/source/window/winproc.cxx:2428
#19 0x7fffebd07ae8 in GtkSalFrame::signalButton (pEvent=0x997480,
frame=0x7fffd8f81c88) at /AOO/main/vcl/unx/gtk/window/gtkframe.cxx:2678
#20 0x7fffea9dbaec in ?? () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#21 0x7fffeb214fa5 in g_closure_invoke () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x7fffeb226fc1 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x7fffeb22f7f9 in g_signal_emit_valist () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x7fffeb23008f in g_signal_emit () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x7fffeaaf393c in ?? () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#26 0x7fffea9da284 in gtk_propagate_event () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#27 0x7fffea9da63b in gtk_main_do_event () from

Debugging Base's "Create Table in Design View"

2017-11-17 Thread Damjan Jovanovic 
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:

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:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN:
source/ui/app/AppController.cxx: case
ID_NEW_TABLE_DESIGN_AUTO_PILOT:
source/ui/app/AppController.cxx:case
ID_NEW_TABLE_DESIGN:
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:MID_NEW_TABLE_DESIGN
source/ui/inc/browserids.hxx:#define ID_NEW_TABLE_DESIGN
25
source/ui/inc/browserids.hxx:#define ID_NEW_TABLE_DESIGN_AUTO_PILOT
45
source/ui/inc/toolbox_tmpl.hrc:#define MID_NEW_TABLE_DESIGN \
source/ui/inc/toolbox_tmpl.hrc:

Re: FYI: The OO 4.1.4 Mac problem

2017-11-17 Thread Damjan Jovanovic 
Thank you :).

What "success code"? Which multiple implementations?

On Fri, Nov 17, 2017 at 4:41 PM, Peter kovacs  wrote:

> Awesome thanks Damjan!
>
> Would it make sense to route the success code through the connectivity
> code for the future?
>
> I would rather like to have one time implementation instead of maintain
> redundant implementations.
> ( the drawback is that bugs have bigger impact. Ofc)
>
>
> Am 17. November 2017 15:26:57 MEZ schrieb Damjan Jovanovic <
> dam...@apache.org>:
> >Hi
> >
> >I am familiar with the database driver code in main/connectivity, but
> >much
> >less familiar with the Base code main/dbaccess where the problem is.
> >
> >On an unrelated past bug in my code in a main/connectivity driver, I
> >did
> >however briefly encounter that same problem where clicking "Create
> >table"
> >does nothing. Debugging it proved very difficult. Far too commonly,
> >Base
> >catches and silently swallows exceptions via the likes of:
> >
> >catch (Exception&) {}
> >
> >which explains why no error is reported to the user, and means that
> >even if
> >you put a breakpoint on such a line, you can't see anything about the
> >exception as there is no variable it's assigned to: not the exception's
> >particular subtype, not its message, and in the abomination that is C++
> >generally, never the most useful part: its stack trace.
> >
> >I then tried doing "catch throw" in gdb to try examine the exception
> >when
> >it's thrown instead of caught, however that took me on a wild goose
> >chase,
> >as multiple harmless exceptions get thrown during the course of that
> >dialog
> >opening.
> >
> >Eventually I gave up and fixed the bug in my main/connectivity driver.
> >I
> >can't remember which bug; probably that null strings were being
> >returned
> >from Java to UNO, and UNO strings can't ever be null (even in AOO's
> >C++,
> >the infamous OUString is always empty, never null).
> >
> >Later I can try to find and send you the beginning of that path through
> >the
> >Base code that's involved in opening the "Create table" dialog, so you
> >have
> >somewhere to start from. Since I don't have a Mac or access to one, I
> >can't
> >help debug this directly. But feel free to ask me any questions.
> >
> >Regards
> >Damjan
> >
> >
> >On Thu, Nov 16, 2017 at 10:12 PM, Dave Fisher 
> >wrote:
> >
> >> Hi Damjan,
> >>
> >> Do you have any tips or pointers regarding the Base issue we are
> >having
> >> with Builds on MacOS?
> >>
> >> I’m seeing your comments on https://bz.apache.org/ooo/
> >> show_bug.cgi?id=126655 and can’t help but wonder if the code is
> >fragile
> >> here. If nothing else some help tracing the code could help.
> >>
> >> Does the Redland configuration and the update in trunk help us here?
> >>
> >> Regards,
> >> Dave
> >>
> >> > On Nov 16, 2017, at 10:40 AM, Jim Jagielski 
> >wrote:
> >> >
> >> > OK, I am pretty much almost out of ideas. I've created a VM which
> >is
> >> > almost an exact match for what I could determine was the build
> >> > environ for 4.1.2. Attached is a patch file that shows the diffs
> >between
> >> > the config.out for 4.1.2 and my build of 4.1.2. My build doesn't
> >suffer
> >> > from the corrupted diagram but it DOES still suffer from the
> >> table/Database
> >> > regression. AFAIK, the official 4.1.2 build suffers from neither.
> >> >
> >> > So what is causing this weird behavior I simply don't know... As
> >> > one can see, there's nothing, at least as reported by config.log,
> >which
> >> is
> >> > different and this is straight from
> >> >
> >> >   https://svn.apache.org/repos/asf/openoffice/tags/AOO412
> >> >
> >> > 
> >> >
> >-
> >> > 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

2017-11-17 Thread Peter kovacs 
Awesome thanks Damjan!

Would it make sense to route the success code through the connectivity code for 
the future?

I would rather like to have one time implementation instead of maintain 
redundant implementations.
( the drawback is that bugs have bigger impact. Ofc)


Am 17. November 2017 15:26:57 MEZ schrieb Damjan Jovanovic :
>Hi
>
>I am familiar with the database driver code in main/connectivity, but
>much
>less familiar with the Base code main/dbaccess where the problem is.
>
>On an unrelated past bug in my code in a main/connectivity driver, I
>did
>however briefly encounter that same problem where clicking "Create
>table"
>does nothing. Debugging it proved very difficult. Far too commonly,
>Base
>catches and silently swallows exceptions via the likes of:
>
>catch (Exception&) {}
>
>which explains why no error is reported to the user, and means that
>even if
>you put a breakpoint on such a line, you can't see anything about the
>exception as there is no variable it's assigned to: not the exception's
>particular subtype, not its message, and in the abomination that is C++
>generally, never the most useful part: its stack trace.
>
>I then tried doing "catch throw" in gdb to try examine the exception
>when
>it's thrown instead of caught, however that took me on a wild goose
>chase,
>as multiple harmless exceptions get thrown during the course of that
>dialog
>opening.
>
>Eventually I gave up and fixed the bug in my main/connectivity driver.
>I
>can't remember which bug; probably that null strings were being
>returned
>from Java to UNO, and UNO strings can't ever be null (even in AOO's
>C++,
>the infamous OUString is always empty, never null).
>
>Later I can try to find and send you the beginning of that path through
>the
>Base code that's involved in opening the "Create table" dialog, so you
>have
>somewhere to start from. Since I don't have a Mac or access to one, I
>can't
>help debug this directly. But feel free to ask me any questions.
>
>Regards
>Damjan
>
>
>On Thu, Nov 16, 2017 at 10:12 PM, Dave Fisher 
>wrote:
>
>> Hi Damjan,
>>
>> Do you have any tips or pointers regarding the Base issue we are
>having
>> with Builds on MacOS?
>>
>> I’m seeing your comments on https://bz.apache.org/ooo/
>> show_bug.cgi?id=126655 and can’t help but wonder if the code is
>fragile
>> here. If nothing else some help tracing the code could help.
>>
>> Does the Redland configuration and the update in trunk help us here?
>>
>> Regards,
>> Dave
>>
>> > On Nov 16, 2017, at 10:40 AM, Jim Jagielski 
>wrote:
>> >
>> > OK, I am pretty much almost out of ideas. I've created a VM which
>is
>> > almost an exact match for what I could determine was the build
>> > environ for 4.1.2. Attached is a patch file that shows the diffs
>between
>> > the config.out for 4.1.2 and my build of 4.1.2. My build doesn't
>suffer
>> > from the corrupted diagram but it DOES still suffer from the
>> table/Database
>> > regression. AFAIK, the official 4.1.2 build suffers from neither.
>> >
>> > So what is causing this weird behavior I simply don't know... As
>> > one can see, there's nothing, at least as reported by config.log,
>which
>> is
>> > different and this is straight from
>> >
>> >   https://svn.apache.org/repos/asf/openoffice/tags/AOO412
>> >
>> > 
>> >
>-
>> > 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

2017-11-17 Thread Damjan Jovanovic 
Hi

I am familiar with the database driver code in main/connectivity, but much
less familiar with the Base code main/dbaccess where the problem is.

On an unrelated past bug in my code in a main/connectivity driver, I did
however briefly encounter that same problem where clicking "Create table"
does nothing. Debugging it proved very difficult. Far too commonly, Base
catches and silently swallows exceptions via the likes of:

catch (Exception&) {}

which explains why no error is reported to the user, and means that even if
you put a breakpoint on such a line, you can't see anything about the
exception as there is no variable it's assigned to: not the exception's
particular subtype, not its message, and in the abomination that is C++
generally, never the most useful part: its stack trace.

I then tried doing "catch throw" in gdb to try examine the exception when
it's thrown instead of caught, however that took me on a wild goose chase,
as multiple harmless exceptions get thrown during the course of that dialog
opening.

Eventually I gave up and fixed the bug in my main/connectivity driver. I
can't remember which bug; probably that null strings were being returned
from Java to UNO, and UNO strings can't ever be null (even in AOO's C++,
the infamous OUString is always empty, never null).

Later I can try to find and send you the beginning of that path through the
Base code that's involved in opening the "Create table" dialog, so you have
somewhere to start from. Since I don't have a Mac or access to one, I can't
help debug this directly. But feel free to ask me any questions.

Regards
Damjan


On Thu, Nov 16, 2017 at 10:12 PM, Dave Fisher  wrote:

> Hi Damjan,
>
> Do you have any tips or pointers regarding the Base issue we are having
> with Builds on MacOS?
>
> I’m seeing your comments on https://bz.apache.org/ooo/
> show_bug.cgi?id=126655 and can’t help but wonder if the code is fragile
> here. If nothing else some help tracing the code could help.
>
> Does the Redland configuration and the update in trunk help us here?
>
> Regards,
> Dave
>
> > On Nov 16, 2017, at 10:40 AM, Jim Jagielski  wrote:
> >
> > OK, I am pretty much almost out of ideas. I've created a VM which is
> > almost an exact match for what I could determine was the build
> > environ for 4.1.2. Attached is a patch file that shows the diffs between
> > the config.out for 4.1.2 and my build of 4.1.2. My build doesn't suffer
> > from the corrupted diagram but it DOES still suffer from the
> table/Database
> > regression. AFAIK, the official 4.1.2 build suffers from neither.
> >
> > So what is causing this weird behavior I simply don't know... As
> > one can see, there's nothing, at least as reported by config.log, which
> is
> > different and this is straight from
> >
> >   https://svn.apache.org/repos/asf/openoffice/tags/AOO412
> >
> > 
> > -
> > 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

2017-11-17 Thread Jim Jagielski 

> On Nov 16, 2017, at 11:56 PM, Peter kovacs  wrote:
> 
> Hi Dave.
> 
> Yea I see. Interesting information!

Agreed!

Esp:
  https://bz.apache.org/ooo/show_bug.cgi?id=126622#c28 


where it's stated that building w/ Sierra and Xcode8 "fixes" the problem.
But that is exactly what my builds were done on. Let me try the optimization
hack discussed.

> 
> I was thinking that maybe the archives have hidden more such marbles. 
> 
> Another idea could be if other developers have also problems in supporting a 
> wide range of Apple  versions?
> Maybe that gives some more hints /ideas.
> 
> As I said I will make  MacOS my focus next week. Building on Sierra. Maybe I 
> see something.
> 
> All the best
> Peter
> 
> Am 16. November 2017 23:51:15 MEZ schrieb Dave Fisher :
>> Hi Peter,
>> 
>> I wasted my time on Sierra and have asked your same question a few
>> times. Andrea just sent a link to a BZ and mail thread regarding how
>> Ariel got 4.1.3 to work. That information only partially made it to the
>> Wiki instructions.
>> 
>> Let’s wait for Jim to absorb this new information and then I want to do
>> the same from a “virgin” Mac with the correct MacOSX.
>> 
>> We need a precise prescription if we need something from either MacPort
>> or Homebrew then PICK ONE! We may need an area to store things that are
>> now hard to download from Apple like JDK 1.7.
>> 
>> Unless Jim has a new version to test I am done until Monday.
>> 
>> Regards,
>> Dave
>> 
>>> On Nov 16, 2017, at 11:06 AM, Peter kovacs  wrote:
>>> 
>>> What is your base for determine the build environment?
>>> 
>>> I want to make time next week to try to build on my MacBook. Maybe I
>> can come up with something. But no promises.
>>> 
>>> Maybe until we have some new idea, we should start with 4.2.0. Is
>> trunk affected too?
>>> 
>>> Am 16. November 2017 19:40:17 MEZ schrieb Jim Jagielski
>> :
 OK, I am pretty much almost out of ideas. I've created a VM which is
 almost an exact match for what I could determine was the build
 environ for 4.1.2. Attached is a patch file that shows the diffs
 between
 the config.out for 4.1.2 and my build of 4.1.2. My build doesn't
>> suffer
 from the corrupted diagram but it DOES still suffer from the
 table/Database
 regression. AFAIK, the official 4.1.2 build suffers from neither.
 
 So what is causing this weird behavior I simply don't know... As
 one can see, there's nothing, at least as reported by config.log,
>> which
 is
 different and this is straight from
 
 https://svn.apache.org/repos/asf/openoffice/tags/AOO412
>>> 
>>> -
>>> 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
>