Bug 87370 - Crash when executing query in SQL View in native mode with Oracle 10g database
Summary: Crash when executing query in SQL View in native mode with Oracle 10g database
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2014-12-16 17:04 UTC by Jared González
Modified: 2015-09-04 03:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

Log de crash (150.82 KB, text/plain)
2014-12-16 17:04 UTC, Jared González
gdb with "bt" (7.56 KB, text/x-log)
2014-12-16 17:06 UTC, Jared González
debug backtrace (11.39 KB, text/x-log)
2014-12-19 02:09 UTC, Jared González
test case (27.95 KB, text/plain)
2014-12-19 02:52 UTC, Jared González

Note You need to log in before you can comment on or make changes to this bug.
Description Jared González 2014-12-16 17:04:28 UTC
Created attachment 110913 [details]
Log de crash

Crash when I execute a query in SQL View in native mode 

Steps to reproduce:
1.- Connect to oracle database
2.- Create a view with this sentence in native mode
"select tablespace_name from dba_tablespaces order by tablespace_name"
2.- Execute query

It works sometimes for someone databases, The crash appear with databases with many tablespaces.

The error appear in:

I send you de core and crash log.

[Depuración de hilo usando libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
El núcleo se generó por «/usr/lib/libreoffice/program/soffice.bin --base spld-biaqagcs.odb --splash-pipe».
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f7a35110bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No existe el archivo o el directorio.
(gdb) bt
#0  0x00007f7a35110bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f7a35113fc8 in __GI_abort () at abort.c:89
#2  0x00007f79f9786919 in os::die() () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#3  0x00007f79f9909c0e in VMError::report_and_die() () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#4  0x00007f79f990a648 in crash_handler(int, siginfo_t*, void*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#5  <signal handler called>
#6  0x00007f7a00009750 in ?? ()
#7  0x00007f79f97868f0 in os::abort(bool) () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#8  0x00007f79f9909f7f in VMError::report_and_die() () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#9  0x00007f79f978f6df in JVM_handle_linux_signal () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#10 <signal handler called>
#11 0x00007f7a0117a8cc in connectivity::ORowSetValue::operator=(connectivity::ORowSetValue const&) ()
   from /usr/lib/libreoffice/program/../program/libdbtoolslo.so
Comment 1 Jared González 2014-12-16 17:06:13 UTC
Created attachment 110914 [details]
gdb with "bt"
Comment 2 Jared González 2014-12-16 17:10:59 UTC
the fall occurs when the version of the database is 10g
Comment 3 Alex Thurgood 2014-12-17 13:49:01 UTC
Change title to better reflect situation.

Please indicate how you are connecting to db server.


I don't have a 10g server so can not test, but we would need at least that much information anyway.

A sample table with data and query that you are tryingto run would be useful too.
Comment 4 Alex Thurgood 2014-12-17 13:52:11 UTC
Also please provide LO version type (official TDF or distrib) and OS details. At the moment, all we know is that you're running 64bit Linux, and Java 7 openjdk
Comment 5 Alex Thurgood 2014-12-17 13:53:53 UTC
OK, so your stack says Ubuntu 14.04 and Oracle JDBC connector
Comment 6 Alex Thurgood 2014-12-17 13:57:37 UTC
Adding other db guys to CC, in case they access to an Oracle server or a better idea of what might be happening.
Comment 7 Alex Thurgood 2014-12-17 13:59:57 UTC
@Jared : reiterating needinfo question

- LO : TDF or Ubunut packaged ?
- sample data, table and query to attempt to reproduce
Comment 8 Lionel Elie Mamane 2014-12-17 14:05:00 UTC
I don't (In reply to Alex Thurgood from comment #5)
> OK, so your stack says Ubuntu 14.04 and Oracle JDBC connector

I don't see "JDBC" in the stack trace...

Jared, if you could repeat the backtrace with a *debug* build of LibreOffice, it would be very helpful.
Comment 9 Jared González 2014-12-17 15:14:02 UTC
I send you the information about of environment

OS: Ubuntu 14.04.1 LTS
Kernel: 3.13.0-43-generic x86_64
Libreoffice: 4.3.4-0ubuntu1~trusty1 (ppa:libreoffice/ppa)
Libreoffice Connection: JDBC using ojdbc6.jar of Oracle Client
Java: OpenJDK Runtime Environment (7u71-2.5.3-0ubuntu0.14.04.1)

The debug backtrace I send you tomorow, Today I don't have access to databases

If I use a Oracle 11g, the problem occurs when I execute a Query and the SQL has a different data type of varchar in first column.

Ex. select sysdate from dual
Comment 10 Alex Thurgood 2014-12-17 22:36:42 UTC
Guessed from crash log :

Comment 11 Alex Thurgood 2014-12-17 22:38:05 UTC
@Jared: does it only crash when getting date time, or timestamp values ?
Just a hunch.
Comment 12 Jared González 2014-12-19 02:09:33 UTC
Created attachment 111025 [details]
debug backtrace
Comment 13 Jared González 2014-12-19 02:10:01 UTC
I send you the debug backtrace
Comment 14 Jared González 2014-12-19 02:51:20 UTC
regarding the type of failure is very consistent with the evidence , but this does not depend on the data type directly

I attached a case of tests with bases oracle 10g and 11g
Comment 15 Jared González 2014-12-19 02:52:17 UTC
Created attachment 111028 [details]
test case
Comment 16 Lionel Elie Mamane 2014-12-19 06:36:25 UTC
Jared, do you know your way around gdb, beyond generating a backtrace?

If yes, I would need to see, from your backtrace:

in frame #12, the value of _rRH, in particular _rRH.m_eTypeKind and _rRH.m_aValue.m_pValue

in frame #13, the value of m_pGetValue and the value of m_nPos

The problem seems to be that m_pGetValue(m_nPos) returns an invalid ORowSetValue...

If no, can you get me access to an Oracle database server?
Comment 17 Lionel Elie Mamane 2014-12-19 06:40:28 UTC
Also, did you by any chance test with an older version of LibreOffice where it worked? The code has changed between LibreOffice 4.2 and 4.3, so it would be very interesting and useful to know if it works with LibreOffice 4.2 (keeping the rest of the environment as unchanged as possible: same JDBC driver version, same DB server, same DB contents, ...). LibreOffice 4.2 can be downloaded from http://www.libreoffice.org/download/libreoffice-fresh/?version=4.2.8
Comment 18 Jared González 2014-12-19 15:43:17 UTC
I send you the information

(gdb) frame 12
#12 connectivity::ORowSetValue::operator= (this=this@entry=0x7fff480450c0, _rRH=...)
    at /build/buildd/libreoffice-4.3.4/connectivity/source/commontools/FValue.cxx:420
420	in /build/buildd/libreoffice-4.3.4/connectivity/source/commontools/FValue.cxx
(gdb) print _rRH
$9 = (const connectivity::ORowSetValue &) @0x3d86da0: {m_aValue = {m_bBool = 48, m_nInt8 = 48 '0', m_uInt8 = 48 '0', 
    m_nInt16 = 48, m_uInt16 = 48, m_nInt32 = 48, m_uInt32 = 48, m_nInt64 = 48, m_uInt64 = 48, m_nFloat = 6.72623263e-44, 
    m_nDouble = 2.3715151000379834e-322, m_pString = 0x30, m_pValue = 0x30}, m_eTypeKind = 801, m_bNull = false, 
  m_bBound = false, m_bModified = false, m_bSigned = false}
(gdb) print _rRH.m_aValue
$10 = {m_bBool = 48, m_nInt8 = 48 '0', m_uInt8 = 48 '0', m_nInt16 = 48, m_uInt16 = 48, m_nInt32 = 48, m_uInt32 = 48, 
  m_nInt64 = 48, m_uInt64 = 48, m_nFloat = 6.72623263e-44, m_nDouble = 2.3715151000379834e-322, m_pString = 0x30, 
  m_pValue = 0x30}

(gdb) frame 13
#13 0x00007fe6fd5bbb8b in dbaccess::ORowSetDataColumn::fireValueChange (this=0x3b7d200, _rOldValue=...)
    at /build/buildd/libreoffice-4.3.4/dbaccess/source/core/api/CRowSetDataColumn.cxx:183
183	/build/buildd/libreoffice-4.3.4/dbaccess/source/core/api/CRowSetDataColumn.cxx: No existe el archivo o el directorio.
(gdb) print m_nPos
$1 = 2

But, I can not retrieve the value of the m_pGetValue variable
Comment 19 Jared González 2014-12-19 15:44:23 UTC
Sorry, I do it

(gdb) print m_pGetValue
$2 = {<boost::function1<connectivity::ORowSetValue const&, int>> = {<boost::function_base> = {
      vtable = 0x7fe6fd99d121 <void boost::function1<connectivity::ORowSetValue const&, int>::assign_to<boost::_bi::bind_t<connectivity::ORowSetValue const&, boost::_mfi::mf1<connectivity::ORowSetValue const&, dbaccess::ORowSet, int>, boost::_bi::list2<boost::_bi::value<dbaccess::ORowSet*>, boost::arg<1> > > >(boost::_bi::bind_t<connectivity::ORowSetValue const&, boost::_mfi::mf1<connectivity::ORowSetValue const&, dbaccess::ORowSet, int>, boost::_bi::list2<boost::_bi::value<dbaccess::ORowSet*>, boost::arg<1> > >)::stored_vtable+1>, functor = {obj_ptr = 0x7fe6fd609be0 <dbaccess::ORowSet::getInsertValue(int)>, type = {
          type = 0x7fe6fd609be0 <dbaccess::ORowSet::getInsertValue(int)>, const_qualified = false, 
          volatile_qualified = false}, func_ptr = 0x7fe6fd609be0 <dbaccess::ORowSet::getInsertValue(int)>, 
        bound_memfunc_ptr = {memfunc_ptr = (void (boost::detail::function::X::*)(boost::detail::function::X * const, 
    int)) 0x7fe6fd609be0 <dbaccess::ORowSet::getInsertValue(int)>, obj_ptr = 0x3c6b890}, obj_ref = {
          obj_ptr = 0x7fe6fd609be0 <dbaccess::ORowSet::getInsertValue(int)>, is_const_qualified = false, 
          is_volatile_qualified = false}, 
        data = -32 '\340'}}, <std::unary_function<int, connectivity::ORowSetValue const&>> = {<No data fields>}, 
    static args = <optimized out>, static arity = <optimized out>}, <No data fields>}
Comment 20 Jared González 2014-12-22 16:44:30 UTC
Do you need more information?
Comment 21 Alex Thurgood 2015-01-03 17:40:26 UTC
Adding self to CC if not already on
Comment 22 Julien Nabet 2015-01-14 21:54:41 UTC
Jared: I think your feedback will certainly help Lionel. Meanwhile, would it be possible give provide extra information asked here: https://bugs.freedesktop.org/show_bug.cgi?id=87370#c17 ?
Comment 23 QA Administrators 2015-07-18 17:36:13 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

This NEEDINFO message was generated on: 2015-07-18
Comment 24 QA Administrators 2015-09-04 03:01:31 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO
Message generated on: 2015-09-03