To reproduce on vanilla LO: 1- Launch Base (./instdir/program/sbase) (Database Wizard opens) 2- Go through the Database Wizard to create a new database: Push these buttons in order: Next -> Finish -> Save 3- Wait for Base to save and open the new database. 4- Click "Tables" in the "Database" pane on the left. 5- Click "Use Wizard to Create Table..." in the "Tasks" pane on the top. 6- Wait for the "Table Wizard" dialog to open 7- Click ">>" button to move all available fields to the Selected fields list. 8- Click "Next >" to go to the "Set field types and formats" step 9- Right or left click on the name of any field in the "Selected fields" list. Observed result: Base crashes. Expected result: The clicked field name is selected.
I can not confirm with Version: 5.2.0.0.alpha0+ Build ID: 0f27cc992a99568e46ffe807ef9dbb5ba0bc601f CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-04-12_23:40:16 If possible, please follow the instructions provided at this link < https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux >. and submit a backtrace. That way a developer can look into the underlying reason of the crash.
Created attachment 124312 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this. I attached a bt with symbols.
I don't reproduce this on LO Debian package 5.1.2.0 => regression
(In reply to Julien Nabet from comment #3) > I don't reproduce this on LO Debian package 5.1.2.0 > => regression Hmm... Not necessarily. This looks like a debug-only assert. Since the Debian package is not built with debug enabled, this does not show a regression.
I'm scratching my head on this one, but I don't catch what's wrong... free() is called incorrectly, but I don't see why. The array is created with new[], and deleted with delete[], so it should be OK.
I get the impression that somehow pOldValues[0].pData and the actual storage of the property point towards the same storage, but don't correctly update reference counts, so that the first one destroyed frees the storage, and when the other one is destroyed it is a double free()
The backtrace smells like memory corruption happened earlier and only now leads to an assert. I cannot reproduce any problem here, with neither an ASan/UBSan build nor with Valgrind. Maybe somebody who can reproduce the problem can try to see if Valgrind turns up anything for them ("VALGRIND=memcheck instdir/program/soffice --base").
With valgrind, the wizard does not even open, I get a SIGSEGV when opening the wizard: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000043026808, pid=5357, tid=68207872 # # JRE version: OpenJDK Runtime Environment (7.0_95) (build 1.7.0_95-b00) # Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea 2.6.4 # Distribution: Debian GNU/Linux 8.2 (jessie), package 7u95-2.6.4-1~deb8u1 # Problematic frame: # J 56 C2 sun.net.www.ParseUtil.encodePath(Ljava/lang/String;Z)Ljava/lang/String; (336 bytes) @ 0x0000000043026808 [0x0000000043026640+0x1c8] # # Core dump written. Default location: /home/master/src/libreoffice/workdirs/libreoffice-5-2/core or core.5357 # # An error report file with more information is saved as: # XXXXXXX/hs_err_pidXXXXX.log
Created attachment 124370 [details] Valgrind trace (but without crash) With Valgrind, I haven't had a crash but perhaps the retrieved trace might be useful. As usual, it's quite polluted by Java parts. Some config info: openjdk version "1.8.0_77-Debian" OpenJDK Runtime Environment (build 1.8.0_77-Debian-8u77-b03-3+b1-b1) OpenJDK 64-Bit Server VM (build 25.77-b1, mixed mode) valgrind-3.11.0 gcc version 5.3.1 20160323 (Debian 5.3.1-13) ldd (Debian GLIBC 2.22-5) 2.22 GNU Make 4.1
Yes, the below part is interesting. I had seen something similar too with my first attempt at Valgrinding this, but then unfortunately updated my JDK (to Fedora's OpenJDK 1.8.0.77-1.b03.fc23) and afterwards could no longer reproduce it. Julien, what version of Java are you using? > ==25248== Invalid write of size 2 > ==25248== at 0x4C2E7A3: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018) > ==25248== by 0x4658B4F0: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x5F323A87: JNIEnv_::GetShortArrayRegion(_jshortArray*, int, int, short*) (jni.h:1744) > ==25248== by 0x5F31D3AE: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:1001) > ==25248== by 0x5F31BCA1: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:626) > ==25248== by 0x5F3324A2: jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (jni_java2uno.cxx:225) > ==25248== by 0x5F33333C: Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call (jni_java2uno.cxx:523) > ==25248== by 0x47701855: ??? > ==25248== by 0x477096C3: ??? > ==25248== by 0x474959D1: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749515F: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4748E4E6: ??? > ==25248== by 0x46575E1A: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x4658F989: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x4659344D: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x5F33890B: JNIEnv_::CallVoidMethodA(_jobject*, _jmethodID*, jvalue const*) (jni.h:1063) > ==25248== by 0x5F336743: jni_uno::Bridge::call_java(_jobject*, _typelib_InterfaceTypeDescription*, int, int, _typelib_TypeDescriptionReference*, _typelib_MethodParameter*, int, void*, void**, _uno_Any**) const (jni_uno2java.cxx:248) > ==25248== by 0x5F3381C7: UNO_proxy_dispatch (jni_uno2java.cxx:765) > ==25248== by 0x2755E04A: cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (cpp2uno.cxx:186) > ==25248== by 0x2755EAC5: cpp_vtable_call (cpp2uno.cxx:377) > ==25248== by 0x27575935: privateSnippetExecutor (in /home/julien/lo/libreoffice/instdir/program/libgcc3_uno.so) > ==25248== by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145) > ==25248== by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145) > ==25248== by 0xC3D3BEA: VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}::operator()() const (vclxwindows.cxx:589) > ==25248== by 0xC3F7B1D: std::_Function_handler<void (), VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871) > ==25248== by 0xC3CA835: std::function<void ()>::operator()() const (functional:2267) > ==25248== by 0xC3BA3CE: VCLXWindowImpl::OnProcessCallbacks(void*) (vclxwindow.cxx:302) > ==25248== by 0xC3BA230: VCLXWindowImpl::LinkStubOnProcessCallbacks(void*, void*) (vclxwindow.cxx:274) > ==25248== by 0xD92229A: Link<void*, void>::Call(void*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so) > ==25248== by 0xD91F133: ImplHandleUserEvent(ImplSVEvent*) (winproc.cxx:1956) > ==25248== by 0xD920AF8: ImplWindowFrameProc(vcl::Window*, unsigned short, void const*) (winproc.cxx:2524) > ==25248== by 0xDE6881E: SalFrame::CallCallback(unsigned short, void const*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so) > ==25248== by 0xDE78C7A: SalGenericDisplay::DispatchInternalEvent() (gendisp.cxx:86) > ==25248== by 0x22EEC073: GtkData::userEventFn(void*) (gtk3gtkdata.cxx:809) > ==25248== by 0x22EEC100: call_userEventFn (gtk3gtkdata.cxx:819) > ==25248== by 0x6DCDFE9: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x6DCE38F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x6DCE43B: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x22EEAF11: GtkData::Yield(bool, bool) (gtk3gtkdata.cxx:467) > ==25248== by 0x22EEE1A2: GtkInstance::DoYield(bool, bool, unsigned long) (gtkinst.cxx:407) > ==25248== by 0xDD2A794: ImplYield(bool, bool, unsigned long) (svapp.cxx:511) > ==25248== by 0xDD265D9: Application::Yield() (svapp.cxx:553) > ==25248== by 0xD7CB9EE: Dialog::Execute() (dialog.cxx:887) > ==25248== by 0xC3DE598: VCLXDialog::execute() (vclxwindows.cxx:2327) > ==25248== by 0xC443843: UnoDialogControl::execute() (dialogcontrol.cxx:617) > ==25248== Address 0x2bad09ba is 0 bytes after a block of size 10 alloc'd > ==25248== at 0x4C29C0F: malloc (vg_replace_malloc.c:299) > ==25248== by 0x4E573F0: rtl_allocateMemory_SYSTEM(unsigned long) (alloc_global.cxx:272) > ==25248== by 0x4E57507: rtl_allocateMemory (alloc_global.cxx:305) > ==25248== by 0x5F3184C9: jni_uno::rtl_mem::allocate(unsigned long) (jni_base.h:221) > ==25248== by 0x5F3251BB: jni_uno::seq_allocate(int, int) (jni_data.cxx:38) > ==25248== by 0x5F31D342: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:998) > ==25248== by 0x5F31BCA1: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:626) > ==25248== by 0x5F3324A2: jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (jni_java2uno.cxx:225) > ==25248== by 0x5F33333C: Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call (jni_java2uno.cxx:523) > ==25248== by 0x47701855: ??? > ==25248== by 0x477096C3: ??? > ==25248== by 0x474959D1: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749515F: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4749598C: ??? > ==25248== by 0x4748E4E6: ??? > ==25248== by 0x46575E1A: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x4658F989: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x4659344D: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so) > ==25248== by 0x5F33890B: JNIEnv_::CallVoidMethodA(_jobject*, _jmethodID*, jvalue const*) (jni.h:1063) > ==25248== by 0x5F336743: jni_uno::Bridge::call_java(_jobject*, _typelib_InterfaceTypeDescription*, int, int, _typelib_TypeDescriptionReference*, _typelib_MethodParameter*, int, void*, void**, _uno_Any**) const (jni_uno2java.cxx:248) > ==25248== by 0x5F3381C7: UNO_proxy_dispatch (jni_uno2java.cxx:765) > ==25248== by 0x2755E04A: cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (cpp2uno.cxx:186) > ==25248== by 0x2755EAC5: cpp_vtable_call (cpp2uno.cxx:377) > ==25248== by 0x27575935: privateSnippetExecutor (in /home/julien/lo/libreoffice/instdir/program/libgcc3_uno.so) > ==25248== by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145) > ==25248== by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145) > ==25248== by 0xC3D3BEA: VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}::operator()() const (vclxwindows.cxx:589) > ==25248== by 0xC3F7B1D: std::_Function_handler<void (), VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871) > ==25248== by 0xC3CA835: std::function<void ()>::operator()() const (functional:2267) > ==25248== by 0xC3BA3CE: VCLXWindowImpl::OnProcessCallbacks(void*) (vclxwindow.cxx:302) > ==25248== by 0xC3BA230: VCLXWindowImpl::LinkStubOnProcessCallbacks(void*, void*) (vclxwindow.cxx:274) > ==25248== by 0xD92229A: Link<void*, void>::Call(void*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so) > ==25248== by 0xD91F133: ImplHandleUserEvent(ImplSVEvent*) (winproc.cxx:1956) > ==25248== by 0xD920AF8: ImplWindowFrameProc(vcl::Window*, unsigned short, void const*) (winproc.cxx:2524) > ==25248== by 0xDE6881E: SalFrame::CallCallback(unsigned short, void const*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so) > ==25248== by 0xDE78C7A: SalGenericDisplay::DispatchInternalEvent() (gendisp.cxx:86) > ==25248== by 0x22EEC073: GtkData::userEventFn(void*) (gtk3gtkdata.cxx:809) > ==25248== by 0x22EEC100: call_userEventFn (gtk3gtkdata.cxx:819) > ==25248== by 0x6DCDFE9: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x6DCE38F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x6DCE43B: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) > ==25248== by 0x22EEAF11: GtkData::Yield(bool, bool) (gtk3gtkdata.cxx:467) > ==25248== by 0x22EEE1A2: GtkInstance::DoYield(bool, bool, unsigned long) (gtkinst.cxx:407) > ==25248== by 0xDD2A794: ImplYield(bool, bool, unsigned long) (svapp.cxx:511) > ==25248== by 0xDD265D9: Application::Yield() (svapp.cxx:553) > ==25248== by 0xD7CB9EE: Dialog::Execute() (dialog.cxx:887)
(In reply to Stephan Bergmann from comment #10) > Yes, the below part is interesting. I had seen something similar too with > my first attempt at Valgrinding this, but then unfortunately updated my JDK > (to Fedora's OpenJDK 1.8.0.77-1.b03.fc23) and afterwards could no longer > reproduce it. > > Julien, what version of Java are you using? > >... As I put in my previous comment: openjdk version "1.8.0_77-Debian" OpenJDK Runtime Environment (build 1.8.0_77-Debian-8u77-b03-3+b1-b1) OpenJDK 64-Bit Server VM (build 25.77-b1, mixed mode)
I can reproduce this on F24 with . ./instdir/program/ooenv beforehand. Debugging into GetShortArrayRegion from libjvm in openjdk I can see that this ends up in openjdk/hotspot/src/share/vm/prims/jni.cpp in a DEFINE_GETSCALARARRAYREGION macro which has... if (len > 0) { \ int sc = TypeArrayKlass::cast(src->klass())->log2_element_size(); \ memcpy((u_char*) buf, \ (u_char*) src->Tag##_at_addr(start), \ len << sc); \ } \ and I can plainly see that log2_element_size for the GetShortArrayRegion case is *2* so we memcpy (len << 2) bytes into the short* output rather than (len << 1) bytes. Where the log2_element_size comes from originally is opaque to me. Its extracted from _layout_helper in the klass, that is 0x80100c02, as the last two bytes. Sort of looks like a bug in openjdk, unless we somehow generate a bad original jshortArray ourselves somewhere.
hmm, so its apparently a [Ljava.lang.Short; and not a [S
ah...
wizards/com/sun/star/wizards/table/FieldFormatter.java has new Short[] not new short[] ecc90694175190cd6e2b9d1bed8f32850d41ce88 transformed them from new short[] to new Short[]
(In reply to Caolán McNamara from comment #15) > wizards/com/sun/star/wizards/table/FieldFormatter.java has new Short[] not > new short[] > > ecc90694175190cd6e2b9d1bed8f32850d41ce88 transformed them from new short[] > to new Short[] Wow, thanks for this detective work. That change looks unrelated to the commit message...
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f53e427291321eabe8d060a737e750a94739f911 Resolves: tdf#99272 new Short[] used instead of new short[] It will be available in 5.2.0. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1ca17f916541ba127765a9f5392fabd761cd946&h=libreoffice-5-1 Resolves: tdf#99272 new Short[] used instead of new short[] It will be available in 5.1.4. 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.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b78551dcf54158adffe3236a45946942af5f354 Related tdf#99272: Prevent bogus com.sun.star.uno.Type(Short[].class) etc. It will be available in 5.2.0. 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.
*** Bug 92580 has been marked as a duplicate of this bug. ***