fs->oj: didn't you say you have too few 3.1 issues?

same stack for dbaccess.ORowSet::com::sun::star::sdbc::XRow

The problem seems to be the java-uno bridge. Only the method getDate from XRow
doesn't work. All other methods are working. The code base inside is the same
for all get methods. The getDate method already breaks with an invalid parameter
which should be > 0 but for this the parameter is -13234134324 or something else.

Trying to reproduce this on DEV300m35, I get

LOG> Can't create object
com.sun.star.sdbc.SQLException: Syntax error in SQL expression
LOG> 	at 
com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:182)
LOG> 	at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:148)
LOG> 	at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:344)
LOG> 	at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:313)
LOG> 	at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:101)
LOG> 	at 
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:65
2)
LOG> 	at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:154)
LOG> 	at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:136)
LOG> 	at $Proxy8.execute(Unknown Source)
LOG> 	at mod._dbaccess.ORowSet.createTestEnvironment(ORowSet.java:352)
LOG> 	at lib.TestCase.getTestEnvironment(TestCase.java:139)
LOG> 	at base.java_fat.executeTest(java_fat.java:195)
LOG> 	at org.openoffice.Runner.main(Runner.java:134)

instead.

@oj: If you can tell me where the implementation of getDate is (and where the test code is that calls it; 
appears not to be in qadevOOo/tests/java/mod/_dbaccess/ORowSet.java), I can have a look whether 
the code looks somehow suspicious.

@oj: please see question in previous comment

Created attachment 57731 [details]
Java sample to reproduce the issue. dbaccess/qa/complex/dbaccess

I attached a Java sample which you have to put in dbaccess/qa/complex/dbaccess
Just type dmake run
The code which is executed on the UNOside can be found in
dbaccess/source/core/api/RowSet.cxx:getDate

All other getXXX(int) are working.

The problem apparently is struct passing in the Mac GCC UNO bridge, OOO300m9 soffice.bin stack is

#0  dbaccess::ORowSet::getDate (this=0xffffff9f, columnIndex=-1332487448) at 
/private/var/automount/so/ws/OOO300/src/dbaccess/source/core/api/RowSet.cxx:1420
#1  0x02f04959 in (anonymous namespace)::callVirtualMethod (pAdjustedThisPtr=0x349be538, 
nVtableIndex=13, pRegisterReturn=0x349ce590, pReturnTypeDescr=0x34a08dc0, bSimpleReturn=1, 
pStackLongs=0xb093db50, nStackLongs=2) at 
/private/var/automount/so/ws/OOO300/src/bridges/source/cpp_uno/gcc3_macosx_intel/uno2cpp.cxx:126
#2  0x02f04c27 in (anonymous namespace)::cpp_call (pThis=0x1e6f62d0, aVtableSlot={offset = 578396128, 
index = 13}, pReturnTypeRef=0x34a08dc0, nParams=1, pParams=0x34a07d40, pUnoReturn=0x349ce590, 
pUnoArgs=0xb093dcc0, ppUnoExc=0xb093dd88) at 
/private/var/automount/so/ws/OOO300/src/bridges/source/cpp_uno/gcc3_macosx_intel/uno2cpp.cxx:288
#3  0x02f0542d in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0x1e6f62d0, 
pMemberDescr=0x34a08e30, pReturn=0x349ce590, pArgs=0xb093dcc0, ppException=0xb093dd88) at 
/private/var/automount/so/ws/OOO300/src/bridges/source/cpp_uno/gcc3_macosx_intel/uno2cpp.cxx:476
#4  0x1fbd0de8 in thisDispatch (pRemoteI=0x1e6f6460, pType=0x34a08e30, pReturn=0x349ce590, 
ppArgs=0x349ce570, ppException=0x349ce530) at 
/so/ws/OOO300/src/bridges/source/remote/static/stub.cxx:180
#5  0x1fbc5040 in bridges_urp::ServerMultiJob::execute (this=0x34a08ea0) at 
/so/ws/OOO300/src/bridges/source/remote/urp/urp_job.cxx:686
#6  0x1fbc5988 in doit (job=0x34a08ea0) at 
/so/ws/OOO300/src/bridges/source/remote/urp/urp_job.cxx:72
#7  0x0094aeed in cppu_threadpool::JobQueue::enter (this=0x34a08da0, nDisposeId=510607376, 
bReturnWhenNoJob=1 '\001') at 
/private/var/automount/so/ws/OOO300/src/cppu/source/threadpool/jobqueue.cxx:120
#8  0x0094b24c in cppu_threadpool::ORequestThread::run (this=0x1e6f4010) at 
/private/var/automount/so/ws/OOO300/src/cppu/source/threadpool/thread.cxx:199
#9  0x0094b53e in cppu_requestThreadWorker (pVoid=0x1e6f4010) at 
/private/var/automount/so/ws/OOO300/src/cppu/source/threadpool/thread.cxx:49
#10 0x0038d1a8 in osl_thread_start_Impl (pData=0x34a020b0) at thread.c:266
#11 0x920926f5 in _pthread_start ()
#12 0x920925b2 in thread_start ()

fixed as cws/sb102/bridges/source/cpp_uno/gcc3_macosx_intel/uno2cpp.cxx@264564 (for whatever 
reason, I could not reproduce by running checkapi as in the original description, but only via cd  
dbaccess/qa/unoapi && dmake)

cws/sb102/bridges/source/cpp_uno/gcc3_macosx_intel/share.hxx@264566 had inadvertently been 
missing from previous -c 264564

.

.