Steps how to reproduce [Reproducible] with parallel Dev-installation of "Version 4.1.0.0.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' > Crash
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.