Steps how to reproduce [Reproducible] with parallel Dev-installation of "Version 188.8.131.52.alpha0+ (Build ID: 094bab7f9097fba62800d3dd578bd42640d8c6e2) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-18_01:35:56" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile:
1. Launch LibO
2. From LibO Start Center: Menu 'Tools -> Options -> Expand LibreOfficeDev Base'
3. Click 'Databases'
To reproduce the crash with server installation of "Version 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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?
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
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?
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
@@ -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 )
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() )
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)
> 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:
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:
Author: Caolán McNamara <firstname.lastname@example.org>
Date: Fri Feb 8 16:48:34 2013 +0000
move paths option page .ui to cui and adapt code
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":
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:
Affected users are encouraged to test the fix and report feedback.