Created attachment 110914 [details]
gdb with "bt"

the fall occurs when the version of the database is 10g

Change title to better reflect situation.


Please indicate how you are connecting to db server.

JBC ?
ODBC ?

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.

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

OK, so your stack says Ubuntu 14.04 and Oracle JDBC connector

Adding other db guys to CC, in case they access to an Oracle server or a better idea of what might be happening.

@Jared : reiterating needinfo question

- LO : TDF or Ubunut packaged ?
- sample data, table and query to attempt to reproduce

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.

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 11.2.0.1
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

Guessed from crash log :

oracle.jdbc.driver.DBConversion

@Jared: does it only crash when getting date time, or timestamp values ?
Just a hunch.

Created attachment 111025 [details]
debug backtrace

I send you the debug backtrace

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

Created attachment 111028 [details]
test case

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?

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

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

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>}

Do you need more information?

Adding self to CC if not already on

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 ?

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: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

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

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