Bug 92580 - Crash: when creating a table via wizard, go back then forth in a step
Summary: Crash: when creating a table via wizard, go back then forth in a step
Status: CLOSED DUPLICATE of bug 99272
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2015-07-06 19:22 UTC by Julien Nabet
Modified: 2016-05-19 18:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (+ G_SLICE=always-malloc) (3.22 KB, text/plain)
2015-07-06 19:22 UTC, Julien Nabet
Details
valgrind log (G_SLICE=always-malloc) (52.48 KB, application/x-tar-gz)
2015-07-06 19:23 UTC, Julien Nabet
Details
Apple crashtrace (91.90 KB, text/plain)
2015-07-13 15:28 UTC, Alex Thurgood
Details
console logs (144.33 KB, text/plain)
2015-08-07 18:36 UTC, Julien Nabet
Details
gdb bt output when stepping through table creation assistant (4.93 KB, text/plain)
2015-12-15 11:57 UTC, Alex Thurgood
Details
bt with debug symbols (3.22 KB, text/plain)
2015-12-15 20:29 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2015-07-06 19:22:34 UTC
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
Comment 1 Julien Nabet 2015-07-06 19:23:24 UTC
Created attachment 117089 [details]
valgrind log (G_SLICE=always-malloc)
Comment 2 Julien Nabet 2015-07-06 19:30:50 UTC
With LO Debian package 4.4.4.2, I don't reproduce this.
Comment 3 Alex Thurgood 2015-07-13 15:27:38 UTC
@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 ?
Comment 4 Alex Thurgood 2015-07-13 15:28:14 UTC
Created attachment 117207 [details]
Apple crashtrace
Comment 5 Alex Thurgood 2015-07-13 15:29:58 UTC
My trace isn't the same as yours, so quite possibly crashing for a different reason (sigh) ?
Comment 6 Alex Thurgood 2015-07-13 15:33:27 UTC
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.
Comment 7 Michael Meeks 2015-07-14 11:56:24 UTC
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 !
Comment 8 Julien Nabet 2015-07-14 20:12:04 UTC
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?
Comment 9 ribotb 2015-07-18 09:53:30 UTC
(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
Comment 10 Buovjaga 2015-07-29 20:06:39 UTC
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)
Comment 11 Buovjaga 2015-07-30 14:03:49 UTC
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)
Comment 12 ribotb 2015-07-30 15:19:18 UTC
(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)
Comment 13 Julien Nabet 2015-07-30 15:44:55 UTC
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! :-)
Comment 14 Julien Nabet 2015-08-01 06:28:33 UTC
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  ()
Comment 15 Julien Nabet 2015-08-01 06:29:57 UTC
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
Comment 16 Julien Nabet 2015-08-01 06:33:28 UTC
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.
Comment 17 Stephan Bergmann 2015-08-04 13:11:47 UTC
(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)
Comment 18 Julien Nabet 2015-08-07 18:36:53 UTC
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.
Comment 19 Julien Nabet 2015-08-07 18:37:29 UTC
BTW, I could reproduce the crash with master sources updated today.
Comment 20 Stephan Bergmann 2015-08-08 08:31:01 UTC
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.
Comment 21 Julien Nabet 2015-08-08 08:34:42 UTC
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! :-)
Comment 22 Alex Thurgood 2015-11-14 08:02:50 UTC
@Julien : are you still seeing this problem in your current master builds ?
Comment 23 ribotb 2015-11-14 09:47:46 UTC
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!?
Comment 24 ribotb 2015-11-14 09:59:26 UTC
(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)
Comment 25 Julien Nabet 2015-11-14 11:30:30 UTC
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
Comment 26 Alex Thurgood 2015-12-15 11:35:06 UTC
@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
Comment 27 Alex Thurgood 2015-12-15 11:36:30 UTC
My Linux master build built on Linux Mint 17.2 (Rafaela)
Comment 28 Alex Thurgood 2015-12-15 11:57:28 UTC
Created attachment 121313 [details]
gdb bt output when stepping through table creation assistant
Comment 29 Alex Thurgood 2015-12-15 12:00:20 UTC
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 ?
Comment 30 Stephan Bergmann 2015-12-15 12:33:37 UTC
(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.
Comment 31 Julien Nabet 2015-12-15 20:29:15 UTC
Created attachment 121325 [details]
bt with debug symbols

Just to give an update with master sources updated today.
Comment 32 Stephan Bergmann 2015-12-16 10:21:32 UTC
(Still cannot reproduce here with my current Linux master build, also does not report any problems in my current Linux master ASan+UBSan build.)
Comment 33 Muhammet Kara 2016-04-22 07:46:32 UTC
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
Comment 34 Julien Nabet 2016-04-22 17:07:49 UTC
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
Comment 35 Julien Nabet 2016-05-17 19:10:10 UTC
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.
Comment 36 Muhammet Kara 2016-05-18 08:06:50 UTC
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?
Comment 37 Caolán McNamara 2016-05-18 13:16:11 UTC

*** This bug has been marked as a duplicate of bug 99272 ***
Comment 38 Julien Nabet 2016-05-19 18:44:32 UTC
On pc Debian x86-64 with master sources updated yesterday + enable-dbgutil, I don't reproduce this.
Thank you! :-)