Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | ODBC connection crash AOO | ||
---|---|---|---|
Product: | Base | Reporter: | r4zoli <r4zoli> |
Component: | code | Assignee: | r4zoli <r4zoli> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Major | ||
Priority: | P2 | CC: | doudou1976, iplaw67, issues, jsc, mechtilde, orw, rbircher |
Version: | 3.4.0 | Keywords: | regression, release_blocker |
Target Milestone: | --- | Flags: | rbircher:
3.4_release_blocker+
|
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
r4zoli
2012-01-29 12:20:28 UTC
Change version to AOO340-dev. I can confirm that there are problems with the odbc connection and mysql. I tested it under Debian 64 bit I installed the ODBC-driber as I published myself some years ago. It works with the version of OpenOffice.org 3.4 beta but NOT with the apache version from 29.01.2012 So I can also confirm the regression Add myself to CC 3.4 Regression and blocker, I comfirm I can reporudce as well. I want to have a developer look at this issue. As I am not very familiar with our database module, I need same help: I have no database at hand. Thus, I would like to use the given use case with a newly created odb file to debug this issue. But, I do not know how a get such a database ODBC connected in our office. Can somebody help me? Thx in advance. A short description how to create ODBC connection to MySQL on localhost server. First download and install MySQL any version 5.1 or 5.5. Then download ODBC driver. Set ODBC connection in Windows control panel, admin tools, data sources. Open any older version of OOo, create new database, with third option, connecting existing database. Save file. Instructions, on OOo wiki: http://wiki.services.openoffice.org/wiki/Connect_MySQLandBase#Using_ODBC_on_Windows Open same file in AOO 3.4m1, crash. reassigned Ok, now I have time to setup the corresponding environment in order to reproduce this defect and to perform a deeper investigation That was hard work to find out which combinations of MySQL Server and MySQL connector ODBC are needed for my system (Windows 7 Pro, 64bit) to create such a test database document. I needed the following: - MySQL Community Server 5.5 (Windows, x86, 64bit) - MySQL Connector/ODBC (Windows, x84, 64bit) - MySQL Connector/ODBC (Windows, x84, 32bit) Now the debugging of the crash can begin. I can confirm that the defect occurs with AOO 3.4, rev. 1296433, but _not_ with OOo 3.3 and OOo 3.4 Beta So far I have figured out that the stack memory is somehow destroyed on a certain ODBC method call under Windows. Can someone please check, if this issue also occurs under other platforms - e.g. MacOS X, Linux? Thanks in advance. root cause: calling convention wrong when calling ODBC functions changed files: - main/unixODBC/iodbcunix.h, revision 1298779 Who can verify the fix in the next developer snapshots? I will check it on win7. @r4zoli: That is great. Thx. Thus, I am assigning this issue to you for the verfication. May be there are also the one or the other who can check the other Windows platforms. can you give me a hint where I can find the next developer snapshot? then I will test it under Debian 64 bit @mechtilde: Sure. We start a build of our developer snapshots each week. The corresponding revision is announced on ooo-dev mailing list. The installation sets are uploaded by the corresponding volunteers during the week and can be found at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots @mechtilde: One request - can please check in advance of the next developer snapshot builds, if the issue occurs under Debian 64 bit. That would be great. The fix I have made - kudos were going to hdu - are only for Windows. I verified the fix in AOO Developer version r1299571. No crash, I can connect to: postgresql 9.1, MySQL 5.1, 5.5, Firebird 2.5, and SQLite 3.3 databases through ODBC connection, under win7. Thanks for the testing. Closing issue. *** Issue 119409 has been marked as a duplicate of this issue. *** |