Created attachment 117088 [details] bt with debug symbols (+ G_SLICE=always-malloc) On pc Debian x86-64 with master sources updated today, I had a crash when doing this: - launch Base - create an empty hsqldb embedded file - open wizard to create a table - select "TaskID" from "Tasks" table, then click right arrow so it's present in "Selected Fields" pane - click Next button - click Back button - click Next button (without having changed anything) => crash
Created attachment 117089 [details] valgrind log (G_SLICE=always-malloc)
With LO Debian package 4.4.4.2, I don't reproduce this.
@Julien : I get an immediate crash after registering the db on OSX, after having previously selected to proceed straight to the table creation wizard at the time the database is saved. In my trace, it looks like a VCL listener is being removed without checking the status of the radio buttons that had selected the launch of the table creation wizard. One for MM ?
Created attachment 117207 [details] Apple crashtrace
My trace isn't the same as yours, so quite possibly crashing for a different reason (sigh) ?
OK, so no crash for me in Version: 5.1.0.0.alpha1+ Build ID: 7f0161d88e3a496361e2209d31cc7e9ef42a677e Locale: fr-FR (fr.UTF-8) this is from yesterday, so more recent than your build on Debian. I'll reset this to unconfirmed and make my previous attachment obsolete, will open new bug report for that.
Unfortunately the valgrind log is not so useful: "Rerun with --error-limit=no to disable this cutoff." Your AMD openCL drivers are creating a -large- amount of false positives unfortunately that swamps any real signal. Would love to re-test (and re-valgrind if it recurrs) with the latest master. Thanks !
With master sources updated today (0a7375e372ee9583d31d44a7cc7b6a21e6197bf1), I still reproduce the crash. I haven't looked at it in detail but bt seems similar. --error-limit=no is put by default in soffice 120 # finally set the valgrind check 121 VALGRINDCHECK="valgrind --tool=$VALGRIND --trace-children=yes $valgrind_skip --num-callers=50 --error-limit=no" 122 echo "use kill -SIGUSR2 pid to dump traces of active allocations" I'm on a laptop i5 with Nvidia control for GPU: julien@julienPC:~/compile-libreoffice/libreoffice/instdir/program$ lspci|grep -i vga 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 525M] (rev a1) Could I disable or enable anything which could help with Valgrind part?
(In reply to Julien Nabet from comment #0) Hi, On Win7/x86, LO crashes in "Save" dialog when I try to save database. No message. However odb file is created. > I had a crash when doing this: > - launch Base > - create an empty hsqldb embedded file > - open wizard to create a table > - select "TaskID" from "Tasks" table, then click right arrow so it's present > in "Selected Fields" pane > - click Next button > - click Back button > - click Next button (without having changed anything) > > => crash No crash for me. Version: 5.1.0.0.alpha1+ Build ID: 122a15f4a6c09d35db58fe3a7b943b5ea79cbe65 TinderBox: Win-x86@39, Branch:master, Time: 2015-07-09_23:27:20 Locale: fr-FR (fr_FR) Bernard
Windows: No crash on table creation, no crash on saving. Linux: crash on DB creation (Finish). Maybe I should update.. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ (x64) Build ID: e92a8b92072284fd7c37d7bb3e1e8fe72a185f35 TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-22_21:46:26 Locale: fi-FI (fi_FI) Ubuntu 15.04 64-bit Version: 5.1.0.0.alpha1+ Build ID: 0bd582834b46dbbc5037310d45bac8885e6f2a07 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-07-14_01:14:35 Locale: en-US (en_US.UTF-8)
Ok now I coul test properly w/ Linux, too. No crash with the button dance. Ubuntu 15.04 64-bit Version: 5.1.0.0.alpha1+ Build ID: 902255645328efde34ddf62227c8278e8dd61ff0 TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-07-30_03:52:32 Locale: en-US (en_US.UTF-8)
(In reply to ribotb from comment #9) > (In reply to Julien Nabet from comment #0) > Hi, > > On Win7/x86, LO crashes in "Save" dialog when I try to save database. > No message. > However odb file is created. > > Version: 5.1.0.0.alpha1+ > Build ID: 122a15f4a6c09d35db58fe3a7b943b5ea79cbe65 > TinderBox: Win-x86@39, Branch:master, Time: 2015-07-09_23:27:20 > Locale: fr-FR (fr_FR) > No more crash when saving odb file with Version: 5.1.0.0.alpha1+ Build ID: 902255645328efde34ddf62227c8278e8dd61ff0 TinderBox: Win-x86@39, Branch:master, Time: 2015-07-30_03:52:07 Locale: fr-FR (fr_FR)
I'll come back from vacation tomorrow.= (after 2 weeks) I'll update my local repo of master source and launch a build from scratch. In brief, I'll be able to give an update in 2 days. Thank you for having given a try! :-)
On pc Debian x86-64 with master sources updated yesterday, I could still reproduce this. [Switching to Thread 0x2aaaaab2a680 (LWP 17790)] 0x00002aaaab2ec107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x00002aaaab2ec107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00002aaaab2ed4e8 in __GI_abort () at abort.c:89 #2 0x00002aaaab32fa20 in malloc_printerr (action=<optimized out>, str=0x2aaaab4190be "free(): invalid pointer", ptr=<optimized out>) at malloc.c:5000 #3 0x00002aaaaacedb43 in rtl_freeMemory_SYSTEM(void*) (p=0x38ca4e0) at /home/julien/compile-libreoffice/libreoffice/sal/rtl/alloc_global.cxx:277 #4 0x00002aaaaacede26 in rtl_freeMemory(void*) (p=0x38ca4e0) at /home/julien/compile-libreoffice/libreoffice/sal/rtl/alloc_global.cxx:347 #5 0x00002aaaad402f76 in cppu::idestroySequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x38ca4e0, pType=0x34fbd40, pTypeDescr=0x34fbd40, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:289 #6 0x00002aaaad402fc6 in cppu::idestructSequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x38ca4e0, pType=0x34fbd40, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:300 #7 0x00002aaaad402162 in cppu::destructSequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSequence=0x38ca4e0, pType=0x34fbd40, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/data.cxx:162 #8 0x00002aaaad4007e7 in cppu::_destructAny(_uno_Any*, void (*)(void*)) (pAny=0x7fffffff0158, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:126 #9 0x00002aaaad403051 in cppu::_destructData(void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pValue=0x7fffffff0158, pType=0x653440, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:319 #10 0x00002aaaad402258 in uno_type_destructData(void*, typelib_TypeDescriptionReference*, uno_ReleaseFunc) (pValue=0x7fffffff0158, pType=0x653440, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/data.cxx:198 #11 0x00002aaae972f354 in jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (this=0x32d15e0, jni=..., pUnoI=0x3754f80, member_td=0x77e0b0, return_type=0x653b40, nParams=2, pParams=0x77e1b0, jo_args=0x7fffffff06b0) at /home/julien/compile-libreoffice/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:301 #12 0x00002aaae973002c in Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call(JNIEnv*, jobject, jlong, jstring, jobjectArray) (jni_env=0x35a89d8, jo_proxy=0x7fffffff06d0, bridge_handle=53286368, jo_method=0x7fffffff06b8, jo_args=0x7fffffff06b0) at /home/julien/compile-libreoffice/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:524 #13 0x00002aaaddf10d98 in () #14 0x0000000099e10e80 in () #15 0x0000000000000000 in ()
java version "1.7.0_75" OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-2) OpenJDK 64-Bit Serverjava version "1.7.0_75" OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-2) OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode) VM (build 24.75-b04, mixed mode) Here's my autogen.input --with-system-odbc --enable-ext-barcode --enable-ext-diagram --enable-ext-hunart --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-postgresql-sdbc --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-dependency-tracking --enable-online-update --enable-extra-sample --enable-extra-template --enable-extra-gallery --enable-python=internal --without-system-mariadb --enable-ext-mariadb-connector --enable-bundle-mariadb --enable-avahi --enable-eot --enable-odk --with-lang=en-US it fr de es pt ru cs hu pl da sv el sk is nl lt --with-myspell-dicts
Stephan: thought you might be interested in this one since bt shows uno part. If needed, I can test a patch even for just retrieving more information.
(In reply to Julien Nabet from comment #16) > Stephan: thought you might be interested in this one since bt shows uno part. > If needed, I can test a patch even for just retrieving more information. cannot reproduce; would be interesting to know what kind of UNO method call is being made (i.e., add something like SAL_DEBUG("dispatching "<<OUString(method_td->aBase.aBase.pTypeName)); before the call to bridge->call_uno(...) in frame #12)
Created attachment 117754 [details] console logs As requested, I added the SAL_DEBUG instruction. I attached console logs with some specific marks to indicate what has been done.
BTW, I could reproduce the crash with master sources updated today.
So looks like in an XPropertySet.setPropertyValue call from Java to binary UNO with the aValue ANY containing some sequence, there's something wrong with that sequence argument, causing a crash while cleaning up the arg at the end of the call, but hard to "remote debug" that any further.
Thank you Stephan for your feedback. If you want me to test other patches to add logs or something else or need the results of a gdb session on a specific code location at a precise moment don't hesitate! :-)
@Julien : are you still seeing this problem in your current master builds ?
Hi, (In reply to Julien Nabet from comment #0) > - launch Base > - create an empty hsqldb embedded file > - open wizard to create a table > - select "TaskID" from "Tasks" table, then click right arrow so it's present > in "Selected Fields" pane > - click Next button > - click Back button > - click Next button (without having changed anything) > No crash with master~2015-10-20(*) on Windows 7/x86 Bernard (*) I can't display "About LibreOfficeDev" (only title bar!?
(In reply to ribotb from comment #23) > > (*) I can't display "About LibreOfficeDev" (only title bar!? After trying several times : Version: 5.1.0.0.alpha1+ Build ID: 97a27b1746286a62c4ac032683a4d9d3df5bd399 TinderBox: Win-x86@39, Branch:master, Time: 2015-10-20_06:28:22 Locale: fr-FR (fr_FR)
With master sources updated today, I still reproduce the crash with same bt (gdb) bt #0 0x00002aaaab31d107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00002aaaab31e4e8 in __GI_abort () at abort.c:89 #2 0x00002aaaab360a20 in malloc_printerr (action=<optimized out>, str=0x2aaaab44a0be "free(): invalid pointer", ptr=<optimized out>) at malloc.c:5000 #3 0x00002aaaaacee28b in rtl_freeMemory_SYSTEM(void*) (p=0x6cecdd0) at /home/julien/compile-libreoffice/libreoffice/sal/rtl/alloc_global.cxx:277 #4 0x00002aaaaacee56f in rtl_freeMemory(void*) (p=0x6cecdd0) at /home/julien/compile-libreoffice/libreoffice/sal/rtl/alloc_global.cxx:347 #5 0x00002aaaad21b3c5 in cppu::idestroySequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x6cecdd0, pType=0x6777bf0, pTypeDescr=0x6777bf0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:289 #6 0x00002aaaad21b416 in cppu::idestructSequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x6cecdd0, pType=0x6777bf0, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:300 #7 0x00002aaaad21a5a8 in cppu::destructSequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSequence=0x6cecdd0, pType=0x6777bf0, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/data.cxx:162 #8 0x00002aaaad218cb6 in cppu::_destructAny(_uno_Any*, void (*)(void*)) (pAny=0x7fffffff00b8, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:126 #9 0x00002aaaad21b4a2 in cppu::_destructData(void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pValue=0x7fffffff00b8, pType=0x6e5610, pTypeDescr=0x0, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/destr.hxx:319 #10 0x00002aaaad21a69f in uno_type_destructData(void*, typelib_TypeDescriptionReference*, uno_ReleaseFunc) (pValue=0x7fffffff00b8, pType=0x6e5610, release=0x0) at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/data.cxx:198 #11 0x00002aaae9e50035 in jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (this=0x6982df0, jni=..., pUnoI=0x6c750d0, member_td=0x812030, return_type=0x6e5d80, nParams=2, pParams=0x812130, jo_args=0x7fffffff0620) at /home/julien/compile-libreoffice/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:301 #12 0x00002aaae9e50cfd in Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call(JNIEnv*, jobject, jlong, jstring, jobjectArray) (jni_env=0x67919d8, jo_proxy=0x7fffffff0640, bridge_handle=110636528, jo_method=0x7fffffff0628, jo_args=0x7fffffff0620) at /home/julien/compile-libreoffice/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:524
@Julien : I can reproduce this on my Linux master 5.2 alpha build of this morning after git pull. First time : As soon as I click on the Next button after moving TaskId to the right hand window pane =>> crash. Second time : I opened the ODB file, then re-start the table creation wizard, select taskid, Next, then Back, then Next ==>> crash. Confirming
My Linux master build built on Linux Mint 17.2 (Rafaela)
Created attachment 121313 [details] gdb bt output when stepping through table creation assistant
I've enclosed a series of bt from gdb when stepping through the table creation wizard. Note how there is a SIGSEGV at almost every button press as we step through the assistant. From my own observations, the SIGSEGV seem to occur when when releasing / acquiring / switching to a new thread. Is there some thread affine issue here ?
(In reply to Alex Thurgood from comment #29) > I've enclosed a series of bt from gdb when stepping through the table > creation wizard. Note how there is a SIGSEGV at almost every button press as > we step through the assistant. From my own observations, the SIGSEGV seem to > occur when when releasing / acquiring / switching to a new thread. Is there > some thread affine issue here ? The JVM (instantiated in the soffice.bin process) routinely runs into SIGSEGV which it handles in its signal handler (typically to synthesize java.lang.NullPointerExceptions). Observing these in gdb is harm- and meaningless.
Created attachment 121325 [details] bt with debug symbols Just to give an update with master sources updated today.
(Still cannot reproduce here with my current Linux master build, also does not report any problems in my current Linux master ASan+UBSan build.)
It couldn't reproduce it with latest build from "lo-linux-dbgutil-daily" on Debian/Pardus x86_64, but it still exists when run LO from latest build (done with "make" on core) from master. I suspect that this issue is related with tdf#99272
With 5bb308a9ad16f6002486a60e4a753693818580b6 and some logs added for another bugtracker, I had the same bt: Program received signal SIGABRT, Aborted. [Switching to Thread 0x2aaaaabaf600 (LWP 1968)] 0x00002aaaab32b478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x00002aaaab32b478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00002aaaab32c8fa in __GI_abort () at abort.c:89 #2 0x00002aaaab36f970 in malloc_printerr (action=<optimized out>, str=0x2aaaab45e4d1 "free(): invalid pointer", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5004 #3 0x00002aaaaacf040b in rtl_freeMemory_SYSTEM (p=0x95c97b0) at /home/julien/lo/libreoffice/sal/rtl/alloc_global.cxx:279 #4 0x00002aaaaacf06ef in rtl_freeMemory (p=0x95c97b0) at /home/julien/lo/libreoffice/sal/rtl/alloc_global.cxx:349 #5 0x00002aaaad8069d4 in cppu::idestroySequence (pSeq=0x95c97b0, pType=0x2db2bd0, pTypeDescr=0x2db2bd0, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/destr.hxx:288 #6 0x00002aaaad806a25 in cppu::idestructSequence (pSeq=0x95c97b0, pType=0x2db2bd0, pTypeDescr=0x0, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/destr.hxx:299 #7 0x00002aaaad805d07 in cppu::destructSequence (pSequence=0x95c97b0, pType=0x2db2bd0, pTypeDescr=0x0, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/data.cxx:160 #8 0x00002aaaad804379 in cppu::_destructAny (pAny=0x7ffffffefff8, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/destr.hxx:125 #9 0x00002aaaad806ab1 in cppu::_destructData (pValue=0x7ffffffefff8, pType=0x6f3c60, pTypeDescr=0x0, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/destr.hxx:318 #10 0x00002aaaad805dfe in uno_type_destructData (pValue=0x7ffffffefff8, pType=0x6f3c60, release=0x0) at /home/julien/lo/libreoffice/cppu/source/uno/data.cxx:196 #11 0x00002aaafd7ba675 in jni_uno::Bridge::call_uno (this=0x7b79790, jni=..., pUnoI=0x9b4fcb0, member_td=0x818e00, return_type=0x6f43d0, nParams=2, pParams=0x818f00, jo_args=0x7fffffff04e8) at /home/julien/lo/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:300 #12 0x00002aaafd7bb33d in Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call (jni_env=0x938f1e0, jo_proxy=0x7fffffff04d0, bridge_handle=129472400, jo_method=0x7fffffff04e0, jo_args=0x7fffffff04e8) at /home/julien/lo/libreoffice/bridges/source/jni_uno/jni_java2uno.cxx:523
On pc Debian x86-64 with master sources updated today + enable-symbols (and so not enable-dbgutil), I don't reproduce this. I'll give a try another time with enable-dbgutil.
I couldn't reproduce the crash with latest build of master. Seems like patches for tdf#99272 have also fixed this bug. Should we close this as FIXED or WORKSFORME?
*** This bug has been marked as a duplicate of bug 99272 ***
On pc Debian x86-64 with master sources updated yesterday + enable-dbgutil, I don't reproduce this. Thank you! :-)