I don’t know if this is related in any way to bug 48775 - “CRASH when opening biblio.odb via tools menu without Base module installed”.

I have installed LOdev without any changes, so Base *should* be present and working ... and if I do a quick test (sorry, I am not into Base ;-), I can at least open, view, and edit the Mac Address Book database from my machine with Base, so Base seems to be installed and to work correctly.

@ Alex Thurgood, Julien Nabet, Rainer Bielefeld:

Hi Alex, Julien and Rainer,

can you reproduce this (or something similar) under Mac OS X 10.8 (Alex) / Linux (Julien) / Windows (Rainer)?

Do you know which developer is responsible for the “Bibliography Database” stuff and should be CC’ed about this bug -- the Writer people, or Lionel (because he is the Base expert)?

Sorry for asking so many help from you, but I am no database expert, so I don’t know where to start with this issue.

Thank you very much!

[Reproducible] with unzipped installation of  "LOdev  4.0.0.0.alpha1+   -  ENGLISH UI / German Locale  [Build ID: af60316514f3ae3d4c475819bf86f2af837171e)]"  {tinderbox: Win-x86@6, pull time 2012-11-23 22:10:31} on German WIN7 Home Premium (64bit) with own separate User Profile.

I will test a later WIN build soon

@ Rainer:
Thank you very much for testing!

Additional hint: “Insert > Indexes and Tables > Bibliography Entry...” works fine and shows all the default entries which used to be in the default bibliography database. IMHO this means that the data are available and the bibliography database works, it is just the “Bibliography Database” dialog itself which fails.

Roman: as soon as the build of my sources will be done, I'll give a try.

I remember having lost changes I had done. Caolán, in this post http://nabble.documentfoundation.org/Patch-for-Easy-Hack-45033-tp3739870p3813088.html, had given the explanation of this lost.
Perhaps you may poke him about this.

Just check gerrit and Bjoern may help here. (see https://gerrit.libreoffice.org/gitweb?p=core.git&a=search&h=HEAD&st=commit&s=bibliography)

Also  [Reproducible] with unzipped  installation of  "LOdev  4.0.0.0.alpha1+   -  ENGLISH UI / German Locale  [Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3)]"  {tinderbox: Win-x86@6, pull time 2012-11-26 00:29:34} on German WIN7 Home Premium (64bit) with own separate User Profile.

It's as Roman stated. The database is available, but the menu Item opens nothing, does nothing.

Sounds like an EasyHack.

On pc Debian x86-64 with master sources updated today (commit 28f54b564e5fd607502bff8c876aaf8064880322), I reproduced this behaviour.

I launched LO from console and when I closed the window, it shutted down but LO doesn't really quit, I don't have the cursor again on console.

Created attachment 70804 [details]
gdb session

Forgot to say there was no specific log.

After a gdb session, it seems the problem is in extensions/source/bibliography/bibload.cxx, this line specifically:
246 return com::sun::star::sdbc::XDriverManager::create(comphelper::getProcessComponentContext()).is();
(function static bool lcl_isBaseAvailable())

I attached a gdb session, it shows that it has a ref to "DriverManager". I'm not sure but it could be the problem.

Then I noticed that if I replaced the content of the function by "return true", the database launched.
However, I noticed afterwards this log a bunch of times:
warn:legacy.tools:14202:1:/home/julien/compile-libreoffice/libo/forms/source/component/FormComponent.cxx:2206: OBoundControlModel::impl_connectDatabaseColumn_noNotify: the form is just *loaded*, but we already have a field!

+ then these logs
warn:legacy.osl:14202:1:/home/julien/compile-libreoffice/libo/unotools/source/config/confignode.cxx:465: caught an exception!
in function:com::sun::star::uno::Any utl::OConfigurationNode::getNodeValue(const rtl::OUString&) const
type: com.sun.star.container.NoSuchElementException
message: DynamicBorderColors
context: N9configmgr10RootAccessE

warn:legacy.osl:14202:1:/home/julien/compile-libreoffice/libo/svx/source/form/fmcontrollayout.cxx:299: OSL_ASSERT: 0

But certainly it must be another bug.

Noel/Stephan: could there be a link with fdo#46808 ? (sorry if I'm wrong, just an idea)

Trying the recipe from comment 0 with a recent master Linux dev-install build (configured --enable-packagekit), the "Bibliography Database" window indeed does not open in step 3, but instead (after some time) a dialog appears "soffice.bin wants to install a package: An additional package is required: libreoffice-base ..."

So I assume this is related to Björn's recent work?  (And the behavior is also wrong, as the install contains Base functionality anyway.)

...and cancelling that dialog and trying to quit LO hangs with

> Thread 5 (Thread 0x7f55e3fff700 (LWP 10541)):
> #0  0x0000003d8bae8bdf in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
> #1  0x0000003d8d647af4 in g_main_context_poll (n_fds=3, fds=0x7f55d80010e0, timeout=-1, context=0x4483ad0, priority=<optimized out>) at gmain.c:3440
> #2  g_main_context_iterate (context=0x4483ad0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3141
> #3  0x0000003d8d647f52 in g_main_loop_run (loop=0x4483a80) at gmain.c:3340
> #4  0x0000003d8f2c94d6 in gdbus_shared_thread_func (user_data=0x4483aa0) at gdbusprivate.c:277
> #5  0x0000003d8d66a495 in g_thread_proxy (data=0x447fcf0) at gthread.c:801
> #6  0x0000003d8be07d14 in start_thread (arg=0x7f55e3fff700) at pthread_create.c:309
> #7  0x0000003d8baf168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

> Thread 1 (Thread 0x7f55f508c840 (LWP 10426)):
> #0  0x0000003d8bae8bdf in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
> #1  0x0000003d8d647af4 in g_main_context_poll (n_fds=4, fds=0x4617520, timeout=10000, context=0x9de7b0, priority=<optimized out>) at gmain.c:3440
> #2  g_main_context_iterate (context=context@entry=0x9de7b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3141
> #3  0x0000003d8d647c14 in g_main_context_iteration (context=0x9de7b0, may_block=1) at gmain.c:3207
> #4  0x00007f55edf26004 in GtkData::Yield (this=0x9963a0, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:587
> #5  0x00007f55edf29b10 in GtkInstance::Yield (this=0x996800, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkinst.cxx:563
> #6  0x00007f55fac6df94 in ImplYield (i_bWait=true, i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:425
> #7  0x00007f55fac6a37f in Application::Yield (i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:459
> #8  0x00007f55e9b5af76 in framework::LoadEnv::waitWhileLoading (this=0x7f55bfd99398, nTimeout=0) at lo/core/framework/source/loadenv/loadenv.cxx:429
> #9  0x00007f55e9adecf0 in framework::LoadDispatcher::impl_dispatch (this=0x7f55bfd99300, rURL=..., lArguments=uno::Sequence of length 6 = {...}, xListener=empty uno::Reference) at lo/core/framework/source/dispatch/loaddispatcher.cxx:122
> #10 0x00007f55e9ade8fc in framework::LoadDispatcher::dispatch (this=0x7f55bfd99300, aURL=..., lArguments=uno::Sequence of length 6 = {...}) at lo/core/framework/source/dispatch/loaddispatcher.cxx:60
> #11 0x00007f55fd89f987 in SfxApplication::OpenDocExec_Impl (this=0x43ebb30, rReq=...) at lo/core/sfx2/source/appl/appopen.cxx:1231
> #12 0x00007f55fd892dce in SfxStubSfxApplicationOpenDocExec_Impl (pShell=0x43ebb30, rReq=...) at lo/core/workdir/unxlngx6/SdiTarget/sfx2/sdi/sfxslots.hxx:1202
> #13 0x00007f55fd981282 in SfxShell::CallExec (this=0x43ebb30, pFunc=0x7f55fd892dab <SfxStubSfxApplicationOpenDocExec_Impl(SfxShell*, SfxRequest&)>, rReq=...) at lo/core/sfx2/inc/sfx2/shell.hxx:188
> #14 0x00007f55fdc552a5 in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned char) () from lo/core/solver/unxlngx6/installation/opt/program/libsfxlo.so
> #15 0x00007f55fdc585ac in SfxDispatcher::PostMsgHandler(SfxRequest*) () from lo/core/solver/unxlngx6/installation/opt/program/libsfxlo.so
> #16 0x00007f55fdc58467 in SfxDispatcher::LinkStubPostMsgHandler(void*, void*) () from lo/core/solver/unxlngx6/installation/opt/program/libsfxlo.so
> #17 0x00007f55fd8a39f4 in Link::Call (this=0x481cf10, pCaller=0x493ffa0) at lo/core/solver/unxlngx6/inc/tools/link.hxx:123
> #18 0x00007f55fdbe1731 in GenLink::Call (this=0x481cf10, pCaller=0x493ffa0) at lo/core/sfx2/inc/sfx2/genlink.hxx:45
> #19 0x00007f55fdbe1655 in SfxHintPoster::Event (this=0x481cf00, pPostedHint=0x493ffa0) at lo/core/sfx2/source/notify/hintpost.cxx:62
> #20 0x00007f55fdbe1762 in SfxHintPoster::DoEvent_Impl (this=0x481cf00, pPostedHint=0x493ffa0) at lo/core/sfx2/source/notify/hintpost.cxx:52
> #21 0x00007f55fdbe162b in SfxHintPoster::LinkStubDoEvent_Impl (pThis=0x481cf00, pCaller=0x493ffa0) at lo/core/sfx2/source/notify/hintpost.cxx:56
> #22 0x00007f55fac55dee in Link::Call (this=0x49cefe0, pCaller=0x493ffa0) at lo/core/solver/unxlngx6/inc/tools/link.hxx:123
> #23 0x00007f55fb183532 in ImplHandleUserEvent (pSVEvent=0x49d1d00) at lo/core/vcl/source/window/winproc.cxx:1987
> #24 0x00007f55fb184819 in ImplWindowFrameProc (pWindow=0x43f9f30, nEvent=22, pEvent=0x49d1d00) at lo/core/vcl/source/window/winproc.cxx:2559
> #25 0x00007f55fb1927cf in SalFrame::CallCallback (this=0x43fa3e0, nEvent=22, pEvent=0x49d1d00) at lo/core/vcl/inc/salframe.hxx:263
> #26 0x00007f55fb1922b6 in SalGenericDisplay::DispatchInternalEvent (this=0xa1f490) at lo/core/vcl/generic/app/gendisp.cxx:92
> #27 0x00007f55edf2708a in GtkData::userEventFn (data=0x9963a0) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:945
> #28 0x00007f55edf270e5 in call_userEventFn (data=0x9963a0) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:955
> #29 0x0000003d8d647825 in g_main_dispatch (context=0x9de7b0) at gmain.c:2539
> #30 g_main_context_dispatch (context=context@entry=0x9de7b0) at gmain.c:3075
> #31 0x0000003d8d647b58 in g_main_context_iterate (context=context@entry=0x9de7b0, block=block@entry=0, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3146
> #32 0x0000003d8d647c14 in g_main_context_iteration (context=0x9de7b0, may_block=0) at gmain.c:3207
> #33 0x00007f55edf25fb2 in GtkData::Yield (this=0x9963a0, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:582
> #34 0x00007f55edf29b10 in GtkInstance::Yield (this=0x996800, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkinst.cxx:563
> #35 0x00007f55fac6df94 in ImplYield (i_bWait=true, i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:425
> #36 0x00007f55fac6a37f in Application::Yield (i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:459
> #37 0x00007f55fac6a320 in Application::Execute () at lo/core/vcl/source/app/svapp.cxx:404
> #38 0x00007f55ff1aee93 in desktop::Desktop::Main (this=0x7fffe1cff4b0) at lo/core/desktop/source/app/app.cxx:1701
> #39 0x00007f55fac7573b in ImplSVMain () at lo/core/vcl/source/app/svmain.cxx:162
> #40 0x00007f55fac75868 in SVMain () at lo/core/vcl/source/app/svmain.cxx:199
> #41 0x00007f55ff1ee09b in soffice_main () at lo/core/desktop/source/app/sofficemain.cxx:74
> #42 0x0000000000400948 in sal_main () at lo/core/desktop/source/app/main.c:48
> #43 0x0000000000400929 in main (argc=2, argv=0x7fffe1cff698) at lo/core/desktop/source/app/main.c:47

@Stephan:
What's your result in a Writer document after <f4>? For me and Roman the biblio. database appears and works quite normal, the problem is limited to menu 'Tools -> Bibliography Database'. And I do not get the " ... additional package ... " message (I waited 10 minutes). Your observation might be a Linux specific different thing, if you can't confirm that <f4> brings up a working Data Sources navigation with Bibilio. contents.

> And I do not get the " ... additional package ... " message
I don’t see it either (on Mac OS), so at least the message seems Linux specific.

(In reply to comment #13)
With parallel installation of  "LOdev  4.0.0.0.alpha1+   -  ENGLISH UI / German Locale  [Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3)]"  {tinderbox: Win-x86@6, pull time 2012-11-26 00:29:34} on German WIN7 Home Premium (64bit) with own separate User Profile  
I can confirm some "hang" effects what might be similar to Stephan's crash.. When I have had tried menu 'Tools -> Bibliography Database' and afterwards I close LibO 4.0 (using window's top right "close-X") the process soffice.bin remains visible in Task Manager.

Yes, I touched that area recently, still Im not yet convinced I am guilty. ;)
Let me elaborate:

http://opengrok.libreoffice.org/xref/core/extensions/source/bibliography/bibload.cxx#260

This tries to get a com::sun::star::sdbc::DriverManager to see if we have Base installed, and if not, it tries to get a org::freedesktop::PackageKit::SyncDBusSessionHelper (which wont work, but wouldnt crash on non-Linux), and then install it.

Yesterday, I tried to make it restart in addition and just to see if it work, I inserted the restart/terminate code there commenting all the other stuff. The result is that LOs window closes, but the process hangs and just doesnt finish. So that trouble seems unrelated to my (then commented changes).

@Roman, @ALL,

On my master build :
Version 4.0.0.0.alpha0+ (Build ID: 2eb947)

on Mac OSX 10.8.2, this works for me. If I click on Tools > Bibliography, the bib database appears (albeit not particularly swiftly, but certainly within the realm of the acceptable, e.g. 1-2 seconds).


Alex

However, in :

Version 4.0.0.0.alpha1+ (Build ID: 8d87128c6bcbac26520a8fef7ae5a6256a82410)

from 26/11/2012, I can confirm that the Bibliography Database entry in the Tools menu no longer does anything.


Alex

Ooh, when I tried to kill the app after it froze, I got the following enclosed trace about some stack misalignment...


Alex

Created attachment 70830 [details]
apple stack trace

@Alex what does the following StarBasic snippet do for you?

Sub Main
xDM = createUnoService("com.sun.star.sdbc.DriverManager")
msgbox xDM.dbg_methods
End Sub

does it pop up a MessageBox or not?

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=27520df57c887488ff4fd5580a9e932f67bd3976

fdo#57696: Missing adaption of OSDBCDriverManager to XDriverManager2



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

was indeed a regression caused by the commits for issue 46808; sorry for the noise

(In reply to comment #21)
> @Alex what does the following StarBasic snippet do for you?
> 
> Sub Main
> xDM = createUnoService("com.sun.star.sdbc.DriverManager")
> msgbox xDM.dbg_methods
> End Sub
> 
> does it pop up a MessageBox or not?

Hi Bjoern,

Yup, this :

Methods of object 
"com.sun.star.sdbc.DriverManager":
SbxEMPTY queryInterface ( SbxOBJECT ) ; 
SbxOBJECT getConnection ( SbxSTRING ) ; 
SbxOBJECT getConnectionWithInfo ( SbxSTRING, SbxARRAY ) ; 
SbxVOID setLoginTimeout ( SbxLONG ) ; 
SbxLONG getLoginTimeout ( void ) ; 
SbxOBJECT getDriverByURL ( SbxSTRING ) ; 
SbxOBJECT getElementType ( void ) ; 
SbxBOOL hasElements ( void ) ; 
SbxOBJECT createEnumeration ( void ) ; 
SbxSTRING getImplementationName ( void ) ; 
SbxBOOL supportsService ( SbxSTRING ) ; 
SbxARRAY getSupportedServiceNames ( void ) ; 
SbxOBJECT getRegisteredObject ( SbxSTRING ) ; 
SbxVOID registerObject ( SbxSTRING, SbxOBJECT ) ; 
SbxVOID revokeObject ( SbxSTRING ) ; 
SbxARRAY getTypes ( void ) ; 
SbxARRAY getImplementationId ( void ) ; 
SbxOBJECT queryAdapter ( void ) 


But I see that Stephan has fixed it in the meanwhile.

Alex

VERIFIED as FIXED with

  Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
  TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0,
  Time: 2012-12-05_22:13:37

on Mac OS X (10.6.8, Intel). Selecting “Tools > Bibliography Database” from the menu bar opens the Expected: “Bibliography Database” window again.


@ Stephan Bergmann:
Thank you very much for fixing this issue!