Typo in above post. In step "16" there should be a query typed in in upper case!

Thanks for bugreport
Please, verify if in last version of LibreOffice still reproducible

Created attachment 64274 [details]
Print-screen of crash window

Verified one more time on LibreOffice v3.5.5.3 on Windows XP. Problem persists.

Ahhh, now I have also noticed the following after changing text in one of text fields and pressing Enter (last 21 step) in LibreOffice v3.5.5.3 Base crashes, but values are correctly updated in IBM DB2 v9.7 table.

So actually functionality works fine, just crashes every time I like to change values in relation database which is plain annoying (and pretty much useless for day-to-day work).

@ Lionel
Greetings
Lionel, what do You think about this bug?

Concerning processing bugreport the problem exists that nobody conforms the bug until today.
Should the facts/request be discussed on a mailinglist? Which ML (perhaps international discuss-ML)?

Set status "UNCONFIRMED" to "NEEDINFO".

@Jochen, I think there is not a problem of "needing more info", so changed status to NEEDINFO is wrong. I (reporter of bug) can reproduce the bug anytime on multiple computers. So I thing bug DOES exists (crash really proves it, doesn't it). The MAIN problem is that it looks NOBODY is using LibreOffice Base to access DB2 database, so there is nobody to confirm if the bug really exists. And because nobody is using Base to access DB2, nobody really cares if it works or not, because it effects only single person (me), so it is insignificant bug. Also to reproduce this bug someone should take the road to download, install and configure DB2 system, and to do this, someone needs to have DB2 knowledge. So too much effort to confirm a bug that only effects single person.

Hi Rainer,
please have a look at comment 7 and comment comment 8.
What is your opinion: change status to "NEW"?

(In reply to comment #8)

> doesn't it). The MAIN problem is that it looks NOBODY is using LibreOffice Base
> to access DB2 database, so there is nobody to confirm if the bug really exists.
> And because nobody is using Base to access DB2, nobody really cares if it works
> or not, because it effects only single person (me), so it is insignificant bug.
> Also to reproduce this bug someone should take the road to download, install
> and configure DB2 system, and to do this, someone needs to have DB2 knowledge.
> So too much effort to confirm a bug that only effects single person.

That is probably true to a certain extent. However, you could help us further by enabling trace logging in your ODBC driver options, and providing that trace log here in the bug issue. So, for the time being, please leave the NEEDINFO status. That would at least enable us to see what might be happening with the calls to the server.

In your title, you mention a "remote" connection. This would imply that your DB2 server and clients (WinXP? Vista? 7?) are not on the same physical machines (unless they're virtualised).

Please provide us with these details.

Alex

@reporter:
please feel free to reopen this bug if you find out that the problem still exists with the current stable LibreOffice version and if you can contribute requested additional information due to (especially BugReport Details)!
Set status to "RESOLVED -> WORKSFORME"

(In reply to comment #11)
> Set status to "RESOLVED -> WORKSFORME"

That's harsh, and wrong. NEEDINFO is right.

@grofaty: Trying to download from http://www-01.ibm.com/software/data/db2/express/download.html fails:

I click on "Get free database / DB2 Express-C 10.1 for Linux 64-bit", then on "Proceed without an IBM ID".

I get error message

 We have no information about the product you requested.
 Please reload the page that brought you here and try again.

 message code: 59e


Trying to download ODBC driver:

 Click "Get database drivers / Data server drivers for Java, .NET, and other platforms", then "Data Server Client Packages (GA level)", then "IBM Data Server Driver for ODBC and CLI (CLI Driver)". No "Proceed without an IBM ID" option.



If you are willing to give me a server to connect to and ODBC drivers I can install (GNU/Linux 64 bits), I'd be interested to take a shot at it. The server could be over a VPN, or a cloud offering (they talk about Amazon EC2 and IBM SmartCloud), or maybe IBM runs a public "play / demo" server?

I *might* be able to do something with an ODBC trace; it depends if something "obvious" is visible in it or not.

Else (unless another developer picks it up), you'll need to give much more info for me to have a shot at it. In particular, run a debug version (with option --norestore) and provide a stack backtrace of the crash.

Alex Thurgood:
>In your title, you mention a "remote" connection.
>This would imply that your
>DB2 server and clients (WinXP? Vista? 7?)
>are not on the same physical machines
>(unless they're virtualised).
I have tried both local database and remove database (all on Windows XP) and there is the same problem. Someone also changed the bug title now which is more correct now.

Lionel Elie Mamane:
>I click on "Get free database
>DB2 Express-C 10.1 for Linux 64-bit", then on
>"Proceed without an IBM ID".
Yes it really returns error message if "Proceed without and IBM ID" is selected, strange... I suggest to register so click on link "Get and IBM ID", enter data into registration form and then download software. It is free of charge.

To install DB2 on Linux I recommend to use the following tutorial:
http://ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/DB2-HOWTO.pdf
It is little bit old, but install process is still the same (just use chapter of distribution you use).

When I reported bug few months ago there was DB2 Express-C 9.7 available, but when IBM releases new version old one is removed from download page. But I have tried the same problem also appears in DB2 Express-C v10.1.

Hi Lionel,

what do you think is now the correct status? Do you need more informations?

Created attachment 66921 [details]
ODBC trace

Since reporting a bug in February now I have migrated:
- DB2 v9.7 ==> DB2 v10.1 (latest stable)
- LibreOffice Base v3.5.0 ==> LibreOffice Base v3.6.1.2 (latest stable)

Now, I have created ODBC trace in Windows XP -> Control Panel | Administrative Tools | Data Sources (ODBC). See attached file odbc_trace.log.

Hope this trace helps. Please let me know if you need something more to confirm a bug.

... I forgot to write that using latest stable DB2 and latest stable LibreOffice Base the problem is EXACTLY the same - crash of LibreOffice appears.

Looking into ODBC trace it looks like there is no problem at all. I did one more test.
a) Executed "select * from mytable" on DB2 command program to check the data in database table.
b) Repeating steps from 1 to including 20.
c) Turn on ODBC trace.
d) Execute step 21 - Base crash appears.
e) Turned off ODBC trace.
f) Looking into the ODBC trace path folder and there is no trace file created.
g) Repeating step a) and I see data are changed in database table by LibreOffice Base.

So it looks to me that ODBC trace is not going to be of any help, because when crash appears there are no traces in ODBC log.

Please let me know if you need some other info?

(In reply to comment #19)

> 
> So it looks to me that ODBC trace is not going to be of any help, because when
> crash appears there are no traces in ODBC log.
> 
> Please let me know if you need some other info?

Without a debug version of LO for Windows and a backtrace, it is going to be nigh on impossible to do anything further. Unfortunately, getting debug symbols for the Windows LO build is somewhat complicated, judging by what I was told this morning - efforts are underway to try and get a debug server up and running for Windows LO builds, but until that happens, we might just have to wait or alternatively, someone can reproduce the problem on another OS.


Alex

I'm going to see what I can do on Mac OSX, I see there is a download for version 9.5.2

However, I would add that this might not work at all, similar to the problem with MyODBC, because LO requires a 32bit driver, and my Mountain Lion 10.8.1 OSX installation only uses 64bit unixODBC and corresponding driver.

At the moment, I don't know how to setup a 32bit driver installation that won't hose my existing 64bit one.


Alex

ODBC 64 bit will only work with 64 bit LO and 32 bit ODBC only with 32 bit LO. It is because ODBC is system library (dll on Windows, so on Linux and so on)

OK, now I have installed DB2 v10.1 on Ubuntu 12.04. Can someone point me to the instruction which software should I install and how to get traces?


P.S. If someone else will install DB2, then you need to install additional packages BEFORE installing DB2:
sudo apt-get -y install libaio1 ksh libstdc+6-4.4-dev libstdc+6-4.4-pic

@grofaty

I would like to poke at this bug a little bit, but I am hung up on
installation of the ODBC driver.  My question of the Express-C forum
<http://www.ibm.com/developerworks/forums/thread.jspa?threadID=457719&tstart>
has been up for ten days without any response.  Sigh!

Suggestions or guidance welcome.


Terry.

(In reply to comment #19)
> Looking into ODBC trace it looks like there is no problem at all. I did one
> more test.
> a) Executed "select * from mytable" on DB2 command program to check the data
> in database table.
> b) Repeating steps from 1 to including 20.
> c) Turn on ODBC trace.
> d) Execute step 21 - Base crash appears.
> e) Turned off ODBC trace.
> f) Looking into the ODBC trace path folder and there is no trace file
> created.

You need to turn ODBC tracing on *before* LibreOffice loads the ODBC driver manager. The easiest is to turn on ODBC tracing before starting LibreOffice.

Cannot reproduce crash under Debian GNU/Linux amd64 (x86-64) with:

 - DB2-C 10.1
 - ODBC/CLI driver 10.1 fixlevel1
 - my (debug) development tree, nor LibreOffice 3.6.2.1
   (Build ID: ba822cc) (Official build / deb amd64)
 - IBM-provided SAMPLE database

Created attachment 68916 [details]
ODBC trace started before LibreOffice

On Windows XP sp3, turned on ODBC tracing, started LibreOffice and recreated the process. See attachment "ODBC trace started before LibreOffice" file.

I can still reproduce the problem in:
- LibreOffice 3.6.2.2
- DB2 Express-C v10.1

(In reply to comment #28)
> Created attachment 68916 [details]
> ODBC trace started before LibreOffice

This attachment seems to be a zip archive, contrary to its mime-type.

Currently BugZilla marks all attachments as plain text by default. We must change type of file for each attachment manually. It is very unhandy and annoying.

Cannot reproduce with:

 LibreOffice Version 3.6.2.2 (Build ID: da8c1e6) on Windows 7 32 bits
 DB2 ODBC driver fixpack1, reported version 10.01.100.145
  (installed as part of complete "v10.1fp1_nt32_dsdriver_EN.exe")
connecting to
 DB2 express 10.1 running on Debian/GNU Linux amd64 (x86-64) over TCP/IP
  installed as normal user (not root)

Exact test:
 Database: SAMPLE as provided with DB2 express, accessed through alias DB2SAMPLE
 Query: SELECT * FROM "MY_USER_NAME"."PRODUCT"
 Edits being done:

   In line with PID='100-100-1', in column NAME
   change 'Snow Shovel, Basic 22 inch' to 'Snow Shovel, Basi 22 inch'.
   Press enter several times or arrow down.
   No crash.

   In line with PID='100-101-1', in column NAME
   change 'Snow Shovel, Deluxe 24 inch' to 'Snow Shovel, Delux 24 inch'.
   Press arrow down.
   No crash.

   In line with PID='100-101-1', in column PID
   change '100-101-1' to '100-101-2'.
   Press arrow down.
   No crash.

Did you try upgrading to the latest FixPacks by IBM (both the DB2 server and the ODBC driver)?


In this situation, I need either an exact test case that will reproduce crash or at least a backtrace.

Exact test case: Basically we need to find out what is different in your test scenario than in mine, because in mine *works*, no crash.
 - dump of database where problem appears
 - explanation of how to load this dump into my local db2 instance
 - .odb file used to access it
 - *exact* steps to reproduce:
   * which column of which row are you editing?
   * replacing which value by what value
   * any other info that could be relevant


backtrace: see http://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_.28on_Windows.29


As a side note, I looked at the ODBC XParameters code in LibreOffice, found a mess and rewrote significant parts of it for LibreOffice 3.7. Maybe a PRE-ALPHA DANGEROUS IT COULD EAT YOUR BABY version of 27 septembre or later will have fixed this issue as a side-product of that rewrite. Or not. See one of (whenever a recent enough build becomes available):
http://dev-builds.libreoffice.org/daily/W2008R2@16-minimal_build/master/
http://dev-builds.libreoffice.org/daily/Win-x86@6/master/
http://dev-builds.libreoffice.org/daily/Win-x86_9-Voreppe/master/

Hi,
I have looked at fixpacks and there is no fixpack 1 available for "DB2 Express-C" version 10.1. You are probably using "DB2 Express" which is NOT! the same edition as I am using. The main difference is "DB2 Express-C" (C in name means community) is free of charge, but "DB2 Express" is paid for subscription license. You can't install "fixpacks" on "DB2 Express-C" edition. Fixpacks are only available for paid versions. Details about differences: http://www.ibm.com/developerworks/data/library/techarticle/dm-1204whicheditiondb2/Figure3.gif

And whole article of comparing DB2 editions: http://www.ibm.com/developerworks/data/library/techarticle/dm-1204whicheditiondb2/

Fixpack page for paid editions:
http://www-01.ibm.com/support/docview.wss?uid=swg27007053

Fixpack 1 is not available for DB2 Express-C.
http://www-01.ibm.com/software/data/db2/express/download.html

"DB2 Express-C" is released from time to time (not in regular basics), so releases can skip some of the fixpacks, but when there are released "DB2 Express-C" already includes fixpacks and full renew installation is required.

So I can't test this fixpack 1 until (and if) fixpack 1 is released for DB2 Express-C v10.1.

I have looked at fixpack 1 bug fix list: http://www-01.ibm.com/support/docview.wss?uid=swg21610653 and I can't see any real fix for ODBC, so I am guessing this problem in LibreOffice accessing DB2 using ODBC still exists.
Regards

(In reply to comment #33)

> I have looked at fixpacks and there is no fixpack 1 available for "DB2
> Express-C" version 10.1. You are probably using "DB2 Express" which is NOT!
> the same edition as I am using.

I don't think I am. I didn't pay for DB2, so it must be the "C" edition. The tarball I downloaded is called db2_v101_linuxx64_expc.tar.gz

> You can't install "fixpacks" on "DB2 Express-C" edition.
> Fixpacks are only available for paid versions.

OK, not for the server, but you can install fixpacks for the ODBC driver. I downloaded v10.1fp1_linuxx64_odbc_cli.tar.gz and v10.1fp1_nt32_dsdriver_EN.exe, and that's what I was testing with as an ODBC driver. (I couldn't get v10.1fp1_nt32_odbc_cli.zip to properly register with the Microsoft ODBC driver manager.)

I'm *guessing* that this may be why it does not crash for me, but then also maybe not. <shrug>


> I have looked at fixpack 1 bug fix list:
> http://www-01.ibm.com/support/docview.wss?uid=swg21610653 and I can't see
> any real fix for ODBC,

It mentions a few crashes in the ODBC driver; most of them look unrelated but maybe 

IC83940	2	[IBM][DB2.NET] SQL0902 AN UNEXPECTED EXCEPTION HAS OCCURRED IN PROCESS. CLI DRIVER CRASHES IN CLI_CSIPOSTCONNECT

Or then, maybe not. We won't know until you try or give me a reproduction case that crashes for me, too :)

Can reproduce the problem. Access violation.
At first glance has nothing to do with underlying databse
Here the offending stack trace:

 	cppu3.dll!cppu::icopyConstructSequence(_sal_Sequence * pSource, _typelib_TypeDescriptionReference * pElementType, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 509 + 0x8 Bytes	C++
 	cppu3.dll!cppu::copyConstructSequence(_sal_Sequence * pSource, _typelib_TypeDescriptionReference * pElementType, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 168 + 0x15 Bytes	C++
 	cppu3.dll!cppu::_copyConstructAnyFromData(_uno_Any * pDestAny, void * pSource, _typelib_TypeDescriptionReference * pType, _typelib_TypeDescription * pTypeDescr, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 308 + 0x1a Bytes	C++
 	cppu3.dll!cppu::_copyConstructAny(_uno_Any * pDestAny, void * pSource, _typelib_TypeDescriptionReference * pType, _typelib_TypeDescription * pTypeDescr, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 362 + 0x1d Bytes	C++
 	cppu3.dll!uno_type_any_construct(_uno_Any * pDest, void * pSource, _typelib_TypeDescriptionReference * pType, void (void *)* acquire)  Zeile 72 + 0x19 Bytes	C++
 	dbtoolslo.dll!552832e3() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für dbtoolslo.dll]	
 	dbtoolslo.dll!552859ad() 	
>	dbalo.dll!lcl_getBookmark(connectivity::ORowSetValue & i_aValue, dbaccess::OCacheSet * i_pCacheSet)  Zeile 493 + 0xd Bytes	C++
 	dbalo.dll!dbaccess::ORowSetCache::getBookmark()  Zeile 508 + 0x35 Bytes	C++
 	dbalo.dll!dbaccess::ORowSetBase::impl_getRow()  Zeile 930 + 0x3c Bytes	C++
 	dbalo.dll!dbaccess::ORowSetBase::getRow()  Zeile 910 + 0xb Bytes	C++
 	svxcorelo.dll!CursorWrapper::getRow()  Zeile 165 + 0x29 Bytes	C++
 	svxcorelo.dll!DbGridControl::SeekCursor(long nRow, unsigned char bAbsolute)  Zeile 2409 + 0x11 Bytes	C++
 	svxcorelo.dll!DbGridControl::SetCurrent(long nNewRow)  Zeile 2099 + 0x11 Bytes	C++
 	svxcorelo.dll!DbGridControl::CursorMoving(long nNewRow, unsigned short nNewCol)  Zeile 2077 + 0x26 Bytes	C++
 	svtlo.dll!svt::EditBrowseBox::IsCursorMoveAllowed(long nNewRow, unsigned short nNewColId)  Zeile 946 + 0x19 Bytes	C++
 	svtlo.dll!BrowseBox::GoToRowColumnId(long nRow, unsigned short nColId)  Zeile 1654 + 0x19 Bytes	C++
 	svtlo.dll!BrowseBox::MouseButtonDown(const BrowserMouseEvent & rEvt)  Zeile 1748	C++
 	svtlo.dll!svt::EditBrowseBox::MouseButtonDown(const BrowserMouseEvent & rEvt)  Zeile 520	C++
 	dbulo.dll!dbaui::SbaGridControl::MouseButtonDown(const BrowserMouseEvent & rMEvt)  Zeile 1129	C++
 	svtlo.dll!BrowserDataWin::MouseButtonDown(const MouseEvent & rEvt)  Zeile 482	C++
 	vcllo.dll!ImplHandleMouseEvent(Window * pWindow, unsigned short nSVEvent, unsigned char bMouseLeave, long nX, long nY, unsigned long nMsgTime, unsigned short nCode, unsigned short nMode)  Zeile 803	C++
 	vcllo.dll!ImplHandleSalMouseButtonDown(Window * pWindow, SalMouseEvent * pEvent)  Zeile 2072 + 0x48 Bytes	C++
 	vcllo.dll!ImplWindowFrameProc(Window * pWindow, SalFrame * __formal, unsigned short nEvent, const void * pEvent)  Zeile 2399 + 0xd Bytes	C++
 	vcllo.dll!SalFrame::CallCallback(unsigned short nEvent, const void * pEvent)  Zeile 278 + 0x2e Bytes	C++
 	vcllo.dll!ImplHandleMouseMsg(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Zeile 3265 + 0x11 Bytes	C++
 	vcllo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef)  Zeile 5630 + 0x15 Bytes	C++
 	vcllo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Zeile 6030 + 0x19 Bytes	C++
 	user32.dll!75528817() 	
 	user32.dll!7552898e() 	
 	user32.dll!75528921() 	
 	user32.dll!75528ab9() 	
 	user32.dll!75528b10() 	
 	vcllo.dll!ImplDispatchMessage(const tagMSG * lpMsg)  Zeile 125	C++
 	vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg)  Zeile 637 + 0x9 Bytes	C++
 	vcllo.dll!ImplSalYield(unsigned char bWait, unsigned char bHandleAllCurrentEvents)  Zeile 668 + 0x9 Bytes	C++
 	vcllo.dll!WinSalInstance::Yield(bool bWait, bool bHandleAllCurrentEvents)  Zeile 713 + 0xf Bytes	C++
 	vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents)  Zeile 435	C++
 	vcllo.dll!Application::Yield(bool i_bAllEvents)  Zeile 468 + 0xc Bytes	C++
 	vcllo.dll!Application::Execute()  Zeile 413 + 0x7 Bytes	C++
 	sofficeapp.dll!desktop::Desktop::Main()  Zeile 1715	C++
 	vcllo.dll!ImplSVMain()  Zeile 173 + 0x15 Bytes	C++
 	vcllo.dll!SVMain()  Zeile 211	C++
 	sofficeapp.dll!soffice_main()  Zeile 83 + 0x5 Bytes	C++
 	soffice.bin!sal_main()  Zeile 48 + 0x6 Bytes	C
 	soffice.bin!main(int argc, char * * argv)  Zeile 47 + 0x1a Bytes	C
 	soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow)  Zeile 47 + 0x28 Bytes	C
 	soffice.bin!__tmainCRTStartup()  Zeile 547 + 0x1c Bytes	C
 	kernel32.dll!7575f13c() 	
 	ntdll.dll!7756d819() 	
 	ntdll.dll!7756da2b()

try to isolate that:

1. create a new table: two columns id and name (varchar)
2. create a row, store
3. open a table, with 1 row: id=1 and name="a"
4. change id=2 and (with cursor) name="b"
5. click on tollbar: store changes => data base operation was okay.
6. put breakpoint in the method ORowSet::moveToInsertRow() in RowSet.cxx
7. back to application, move cursor to the next (non existent) row.
8. breakpoint hit... step through, on line 1195 bang!

void SAL_CALL ORowSet::moveToInsertRow(  ) throw(SQLException, RuntimeException)
{
[...]
ACCESS VIOLATION HAPPENS HERE => aOldValues = new ORowSetValueVector( *(*(m_pCache->m_aMatrixIter)) );

And the stack trace is:

>	cppu3.dll!cppu::icopyConstructSequence(_sal_Sequence * pSource, _typelib_TypeDescriptionReference * pElementType, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 509 + 0x8 Bytes	C++
 	cppu3.dll!cppu::copyConstructSequence(_sal_Sequence * pSource, _typelib_TypeDescriptionReference * pElementType, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 168 + 0x15 Bytes	C++
 	cppu3.dll!cppu::_copyConstructAnyFromData(_uno_Any * pDestAny, void * pSource, _typelib_TypeDescriptionReference * pType, _typelib_TypeDescription * pTypeDescr, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 308 + 0x1a Bytes	C++
 	cppu3.dll!cppu::_copyConstructAny(_uno_Any * pDestAny, void * pSource, _typelib_TypeDescriptionReference * pType, _typelib_TypeDescription * pTypeDescr, void (void *)* acquire, _uno_Mapping * mapping)  Zeile 362 + 0x1d Bytes	C++
 	cppu3.dll!uno_type_any_construct(_uno_Any * pDest, void * pSource, _typelib_TypeDescriptionReference * pType, void (void *)* acquire)  Zeile 72 + 0x19 Bytes	C++
 	dbtoolslo.dll!552432e3() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für dbtoolslo.dll]	
 	dbtoolslo.dll!55275c40() 	
 	dbtoolslo.dll!55244c62() 	
 	dbalo.dll!std::_Construct<connectivity::ORowSetValue,connectivity::ORowSetValue const &>(connectivity::ORowSetValue * _Ptr, const connectivity::ORowSetValue & _Val)  Zeile 48 + 0x34 Bytes	C++
 	dbalo.dll!std::allocator<connectivity::ORowSetValue>::construct(connectivity::ORowSetValue * _Ptr, const connectivity::ORowSetValue & _Val)  Zeile 197 + 0xd Bytes	C++
 	dbalo.dll!std::_Cons_val<std::allocator<connectivity::ORowSetValue>,connectivity::ORowSetValue,connectivity::ORowSetValue const &>(std::allocator<connectivity::ORowSetValue> & _Alval, connectivity::ORowSetValue * _Pdest, const connectivity::ORowSetValue & _Src)  Zeile 281	C++
 	dbalo.dll!std::_Uninit_copy<std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > >,connectivity::ORowSetValue *,std::allocator<connectivity::ORowSetValue> >(std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _First, std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _Last, connectivity::ORowSetValue * _Dest, std::allocator<connectivity::ORowSetValue> & _Al, std::_Nonscalar_ptr_iterator_tag __formal)  Zeile 376 + 0x16 Bytes	C++
 	dbalo.dll!std::_Uninitialized_copy<std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > >,connectivity::ORowSetValue *,std::allocator<connectivity::ORowSetValue> >(std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _First, std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _Last, connectivity::ORowSetValue * _Dest, std::allocator<connectivity::ORowSetValue> & _Al)  Zeile 414 + 0x2d Bytes	C++
 	dbalo.dll!std::vector<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> >::_Ucopy<std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > >(std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _First, std::_Vector_const_iterator<std::_Vector_val<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > > _Last, connectivity::ORowSetValue * _Ptr)  Zeile 1318 + 0x18 Bytes	C++
 	dbalo.dll!std::vector<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> >::vector<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> >(const std::vector<connectivity::ORowSetValue,std::allocator<connectivity::ORowSetValue> > & _Right)  Zeile 539 + 0x2c Bytes	C++
 	dbalo.dll!connectivity::ORefVector<connectivity::ORowSetValue>::ORefVector<connectivity::ORowSetValue>(const connectivity::ORefVector<connectivity::ORowSetValue> & _rRH)  Zeile 79 + 0x41 Bytes	C++
 	dbalo.dll!connectivity::ORowVector<connectivity::ORowSetValue>::ORowVector<connectivity::ORowSetValue>(const connectivity::ORowVector<connectivity::ORowSetValue> & __that)  + 0x32 Bytes	C++
 	dbalo.dll!dbaccess::ORowSet::moveToInsertRow()  Zeile 1195 + 0x3a Bytes	C++
 	frmlo.dll!frm::ODatabaseForm::moveToInsertRow()  Zeile 3596 + 0x1d Bytes	C++
 	svxcorelo.dll!DbGridControl::SetCurrent(long nNewRow)  Zeile 2119 + 0x26 Bytes	C++
 	svxcorelo.dll!DbGridControl::CursorMoving(long nNewRow, unsigned short nNewCol)  Zeile 2077 + 0x26 Bytes	C++
 	svtlo.dll!svt::EditBrowseBox::IsCursorMoveAllowed(long nNewRow, unsigned short nNewColId)  Zeile 946 + 0x19 Bytes	C++
 	svtlo.dll!BrowseBox::GoToRow(long nRow, unsigned char bRowColMove, unsigned char bKeepSelection)  Zeile 1512 + 0x27 Bytes	C++
 	svtlo.dll!BrowseBox::Dispatch(unsigned short nId)  Zeile 1917 + 0x18 Bytes	C++
 	svtlo.dll!svt::EditBrowseBox::Dispatch(unsigned short _nId)  Zeile 619	C++
 	svxcorelo.dll!DbGridControl::Dispatch(unsigned short nId)  Zeile 3056	C++
 	svtlo.dll!svt::EditBrowseBox::PreNotify(NotifyEvent & rEvt)  Zeile 731	C++
 	svxcorelo.dll!DbGridControl::PreNotify(NotifyEvent & rEvt)  Zeile 3369	C++
 	vcllo.dll!Window::PreNotify(NotifyEvent & rNEvt)  Zeile 5096 + 0x23 Bytes	C++
 	vcllo.dll!Window::PreNotify(NotifyEvent & rNEvt)  Zeile 5096 + 0x23 Bytes	C++
 	vcllo.dll!SpinField::PreNotify(NotifyEvent & rNEvt)  Zeile 973 + 0x1a Bytes	C++
 	svtlo.dll!FormattedField::PreNotify(NotifyEvent & rNEvt)  Zeile 578	C++
 	vcllo.dll!ImplCallPreNotify(NotifyEvent & rEvt)  Zeile 85 + 0x1c Bytes	C++
 	vcllo.dll!ImplHandleKey(Window * pWindow, unsigned short nSVEvent, unsigned short nKeyCode, unsigned short nCharCode, unsigned short nRepeat, unsigned char bForward)  Zeile 1101 + 0x9 Bytes	C++
 	vcllo.dll!ImplWindowFrameProc(Window * pWindow, SalFrame * __formal, unsigned short nEvent, const void * pEvent)  Zeile 2439 + 0x25 Bytes	C++
 	vcllo.dll!SalFrame::CallCallback(unsigned short nEvent, const void * pEvent)  Zeile 278 + 0x2e Bytes	C++
 	vcllo.dll!ImplHandleKeyMsg(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, long & rResult)  Zeile 3724 + 0x11 Bytes	C++
 	vcllo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef)  Zeile 5665 + 0x19 Bytes	C++
 	vcllo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Zeile 6030 + 0x19 Bytes	C++
 	user32.dll!75528817() 	
 	user32.dll!7552898e() 	
 	user32.dll!75528921() 	
 	user32.dll!75528ab9() 	
 	user32.dll!75528b10() 	
 	vcllo.dll!ImplDispatchMessage(const tagMSG * lpMsg)  Zeile 125	C++
 	vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg)  Zeile 637 + 0x9 Bytes	C++
 	vcllo.dll!ImplSalYield(unsigned char bWait, unsigned char bHandleAllCurrentEvents)  Zeile 668 + 0x9 Bytes	C++
 	vcllo.dll!WinSalInstance::Yield(bool bWait, bool bHandleAllCurrentEvents)  Zeile 713 + 0xf Bytes	C++
 	vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents)  Zeile 435	C++
 	vcllo.dll!Application::Yield(bool i_bAllEvents)  Zeile 468 + 0xc Bytes	C++
 	vcllo.dll!Application::Execute()  Zeile 413 + 0x7 Bytes	C++
 	sofficeapp.dll!desktop::Desktop::Main()  Zeile 1715	C++
 	vcllo.dll!ImplSVMain()  Zeile 173 + 0x15 Bytes	C++
 	vcllo.dll!SVMain()  Zeile 211	C++
 	sofficeapp.dll!soffice_main()  Zeile 83 + 0x5 Bytes	C++
 	soffice.bin!sal_main()  Zeile 48 + 0x6 Bytes	C
 	soffice.bin!main(int argc, char * * argv)  Zeile 47 + 0x1a Bytes	C
 	soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow)  Zeile 47 + 0x28 Bytes	C
 	soffice.bin!__tmainCRTStartup()  Zeile 547 + 0x1c Bytes	C
 	kernel32.dll!7575f13c() 	
 	ntdll.dll!7756d819() 	
 	ntdll.dll!7756da2b()

it seems that the memory get corrupted somehow. To track it down the follow helper method was introduced (it is missing in ORowSetValue class):

static OString valueToString(ORowSetValue& value)
{
OStringBuffer buf;
buf.append("value kind: ");
buf.append(value.getTypeKind());
if (value.getTypeKind() == 2000)
{
    buf.append(" | value address: ");
    char stream[20];
    sprintf(stream, "%x", value.getValue());
    buf.append(stream);
}
return buf.makeStringAndClear();
}

and used in :

void OCacheSet::fillValueRow(ORowSetRow& _rRow,sal_Int32 _nPosition)
{
[...]
    (*aIter) = aBookmark;
    ++aIter;
[...]

to check which value get assigned to 0 index element (bookmark):

for(int i = 0; testIter != _rRow->get().end(); ++testIter, i++)
{
    OString info = valueToString(*testIter);
    SAL_INFO("dbaccess", "OCacheSet::fillValueRow value pos - address: " << i << " " << info.getStr());
}

-info	{pData=0x0779ed98 }	rtl::OString
+pData	0x0779ed98 {refCount=1 length=41 buffer=0x0779eda0 "value kind: 2000 | value address: 0x05a04d30" }	_rtl_String *

after that the memory "0x05a04d30" points to the valid Any address.
However in this method it get corrupted somehow:

void SAL_CALL ORowSet::moveToInsertRow() throw(SQLException, RuntimeException)
{
[...]
if ( rowDeleted() )
{
    positionCache( MOVE_FORWARD );
    m_pCache->next();
    setCurrentRow( sal_True, sal_False, aOldValues, aGuard);
}
else
{
    // the next statement still ok, the memory "0x05a04d30" is valid.
    checkCorruption = new ORowSetValueVector( *(*(m_pCache->m_aMatrixIter)) );
    // after that line the content of matrixIterator get corrupted:
    positionCache( MOVE_NONE_REFRESH_ONLY );
}

Access violation on the next line, because the same memory "0x05a04d30" as above doesn't points to the valid Any address any more:
checkCorruption = new ORowSetValueVector( *(*(m_pCache->m_aMatrixIter)) );

Created attachment 70522 [details]
odbc trace that shows the driver bug

David Ostrovsky successfully setup a Windows machine (with DB2 Express / Community / ... server *and* client), which indeed reproduces this problem. We collaborated on this and looked into it "completely"

After deep analysis with a debugger, I came to the conclusion that this is a bug of the DB2Express ODBC driver. I'll explain this through attachment 70522 [details]:

First LibreOffice binds the bookmark column (number 0) to the buffer at address 0x070F1DE0:

program"        e3c-d2c	ENTER SQLBindCol 
		HSTMT               02F69FD0
		UWORD                        0 
		SWORD                       -2 <SQL_C_BINARY>
		PTR                0x070F1DE0
		SQLLEN                     4
		SQLLEN *            0x00D7EB5C

program"        e3c-d2c	EXIT  SQLBindCol  with return code 0 (SQL_SUCCESS)
		HSTMT               02F69FD0
		UWORD                        0 
		SWORD                       -2 <SQL_C_BINARY>
		PTR                0x070F1DE0
		SQLLEN                     4
		SQLLEN *            0x00D7EB5C (0)

Then we actually fetch the row, including the bookmark:

program"        e3c-d2c	ENTER SQLBulkOperations 
		SQLHSTMT            02F69FD0
		SQLSMALLINT                  5 

program"        e3c-d2c	EXIT  SQLBulkOperations  with return code 0 (SQL_SUCCESS)
		SQLHSTMT            02F69FD0
		SQLSMALLINT                  5 


Immediately after, we unbind *ALL* columns:

program"        e3c-d2c	ENTER SQLFreeStmt 
		HSTMT               02F69FD0
		UWORD                        2 <SQL_UNBIND>

program"        e3c-d2c	EXIT  SQLFreeStmt  with return code 0 (SQL_SUCCESS)
		HSTMT               02F69FD0
		UWORD                        2 <SQL_UNBIND>


From this moment on, DB2 Express has *no* reason to write in that buffer anymore. Nada, forbidden, not allowed.

*But*, later when we fetch a row identified by a bookmark at another place in memory, the "old" buffer is overriden!!!:

program"        e3c-d2c	ENTER SQLSetStmtAttr 
		SQLHSTMT            02F69FD0
		SQLINTEGER                  16 <SQL_ATTR_FETCH_BOOKMARK_PTR>
		SQLPOINTER          077C21E0
		SQLINTEGER                  -4 

program"        e3c-d2c	EXIT  SQLSetStmtAttr  with return code 0 (SQL_SUCCESS)
		SQLHSTMT            02F69FD0
		SQLINTEGER                  16 <SQL_ATTR_FETCH_BOOKMARK_PTR>
		SQLPOINTER          077C21E0
		SQLINTEGER                  -4 

AT THIS POINT *(void**)0x070f1de0 has some value

program"        e3c-d2c	ENTER SQLFetchScroll 
		SQLHSTMT            02F69FD0
		SQLSMALLINT                  8 <SQL_FETCH_BOOKMARK>
		SQLLEN                     0

program"        e3c-d2c	EXIT  SQLFetchScroll  with return code 0 (SQL_SUCCESS)
		SQLHSTMT            02F69FD0
		SQLSMALLINT                  8 <SQL_FETCH_BOOKMARK>
		SQLLEN                     0


AT THIS POINT *(void**)0x070f1de0 has ANOTHER value



Since even later, LibreOffice tries to dereference the pointer stored there, this leads to a crash.