Summary: | CRASH when FILEOPEN Tools - Options - Base - Databases | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Rainer Bielefeld Retired <LibreOffice> |
Component: | UI | Assignee: | Caolán McNamara <caolanm> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | medium | CC: | caolanm, LibreOffice, lionel, lo_bugs, nikolaj.stenberg, serval2412 |
Version: | 4.1.0.0.alpha0+ Master | ||
Hardware: | Other | ||
OS: | All | ||
See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=61688 | ||
Whiteboard: | target:4.1.0 | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 60270 | ||
Attachments: |
backtrace from SIGABRT
console + bt with symbols on master sources |
Description
Rainer Bielefeld Retired
2013-03-18 16:04:03 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.