To reproduce the crash with server installation of  "Version 4.1.0.0.alpha0+ (Build ID: 576da8db5577f84d9c7e0e40ef3e166a7938c98) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-11_23:54:45" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with own separate User Profile:

I first had to open a .odb (for example sample database in test kit Attachment 75215 [details] for Bug 60166) from file menu. Then proceeding corresponding to report reproduces crash.
Same with Version 4.1.0.0.alpha0+ (Build ID: 7ee2857ab5daa791d36615d149ee562020b883e)
TinderBox: Win-x86@7-MinGW, Branch:master, Time: 2013-02-17_08:19:43

No crash  with server installation of  "Version 4.1.0.0.alpha0+ (Build ID: 2823789bec0c029d9714aff0ed65923e23177ef) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-01-24_22:52:49" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LO41 Masters User Profile

Created attachment 76706 [details]
backtrace from SIGABRT

I see this in master commit 51a18f9, pulled around 2013-03-14 17:40 UTC.

This is the same assertion that was raised in fdo##61688 "SIGABRT with
debug build in VclBuilder::handleChild", and it results from the same line
of "application" code in VclBuilder::handleChild.  Of course, the call
stack beyond that function is quite different.  Perhaps this bug should be
marked duplicate of fdo#61688?

@Rainer,

Is it the case that the failing build is configured with --enable-dbgutil?
I think that that is implicated in the crash, although in comment 6 to
fdo#68688 Juilen Nabet indicates that one build configured that way did not
crash.

@Julien,

What does your "not crashing over there" build do on this bug?

My crash was on Linux 32-bit, so setting platform ALL.

@Terrence Enger (In reply to comment #3)
Where can I check that?

@Rainer,

In the top-level directory of the build, `cat autogen.lastrun`.

Created attachment 76711 [details]
console + bt with symbols on master sources

On pc Debian x86-64 with master sources updated yesterday (commit 84e4bf884718fcca8934b81b4037e063cf08c71e), I reproduced the crash.

I attached bt.

Caolán: you might be interested in this one too, "cui/source/options/dbregister.cxx" is in the bt

At least, this naive patch prevents from the crash on my laptop.

diff --git a/cui/source/options/dbregister.cxx b/cui/source/options/dbregister.cxx
index dfa2def..1d86dc1 100644
--- a/cui/source/options/dbregister.cxx
+++ b/cui/source/options/dbregister.cxx
@@ -312,7 +312,7 @@ IMPL_LINK_NOARG(DbRegistrationOptionsPage, EditHdl)
 
 IMPL_LINK( DbRegistrationOptionsPage, HeaderSelect_Impl, HeaderBar*, pBar )
 {
-    if ( pBar && pBar->GetCurItemId() != ITEMID_TYPE )
+    if ( !pBar || pBar->GetCurItemId() != ITEMID_TYPE )
         return 0;
 
     HeaderBarItemBits nBits = pBar->GetItemBits(ITEMID_TYPE);
@@ -341,7 +341,7 @@ IMPL_LINK( DbRegistrationOptionsPage, HeaderSelect_Impl, HeaderBar*, pBar )
 
 IMPL_LINK( DbRegistrationOptionsPage, HeaderEndDrag_Impl, HeaderBar*, pBar )
 {
-    if ( pBar && !pBar->GetCurItemId() )
+    if ( !pBar || !pBar->GetCurItemId() )
         return 0;
 
     if ( !pBar->IsItemMode() )

(In reply to comment #6)
I am a USER, no idea what we are talking about. Is that really something I can access in a tinderbox build?

(In reply to comment #6)
> @Rainer,
> 
> In the top-level directory of the build, `cat autogen.lastrun`.
Hope I don't misunderstand but if Rainer took Win-x86@6, it must correspond to this config:
http://dev-builds.libreoffice.org/daily/master/Win-x86@6/current/master~2013-03-19_02.28.02_build_info.txt
I don't see any dgb-util or other debug on this file.
Also, I read that LO in Windows (32 or 64 bits) is always 32bits.

*** Bug 57858 has been marked as a duplicate of this bug. ***

@caolanm: this looks like it could be related to:


commit 705b60f94ea5721662811501594d13d1ad925eb3
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Fri Feb 8 16:48:34 2013 +0000

    move paths option page .ui to cui and adapt code
    
    Change-Id: I60063a0d101ef47271194e45ee59f9ff622a4f1c


There, you replaced (in the first code location mentioned in comment 9) pHeaderBar by pBar. I don't quite understand this change, but it smells like pBar is NULL (or otherwise invalid) when pHeaderBar was not. Any insight on that?

yeah, this is my regression

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=944bc0a3a33f21f59cb51a4391687ff1fe01dae9

Resolves: fdo#62478 crash on tools->options->base->databases



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.