Apache OpenOffice (AOO) Bugzilla – Issue 22232
Crash on connect, ODBC/FreeTDS/MSSQL7
Last modified: 2006-05-31 14:29:06 UTC
This report was submitted by a user of the Debian packages. Looking at cws_srx645_dba01pp1, I wonder if the commit '#112539# check if metadata are null!' might have already solved it, but I don't have access to that internal bug to confirm the symptoms of that bug. -------------- Date: Thu, 6 Nov 2003 11:38:24 -0500 From: William Thompson Subject: openoffice.org: Crashes with database (ODBC/FreeTDS/MSSQL7) Package: openoffice.org Version: 1.1.0-1 Severity: important I attempt to retrieve tables from a database that is in an MSSQL7 server and oo crashes with sig 11. I also downloaded OO precompiled from openoffice.org to see if this was debian specific or an OO problem. It's an OO problem. I'm using unixODBC with FreeTDS. I tested the ODBC with isql first. I started OO immediately after installation with a new spreadsheet. I added the data base into OO's data sources with username set and password required. When I expand tables, it asks for the password and once I enter it, OO crashes. The database has 92 tables defined. I am unable to test against another database or another mssql server as this is all I have access to. ------------ Date: Thu, 6 Nov 2003 14:42:17 -0500 > I can see 71 open upstream issues about database crashes and it would be > useful to narrow it down a little. Could you run OOo in a console > window and post the output to the bug? You should find that you get a > stack dump after the crash dialog appears. I still have the original crash (the debian version) in my scroll back. Here it is: [root@potato:/usr/lib/openoffice/program] ./scalc sh: crash_report: command not found Fatal exception: Signal 11 Stack: /usr/lib/openoffice/program/libsal.so.3[0x40bdda3e] /usr/lib/openoffice/program/libsal.so.3[0x40bddbcb] /usr/lib/openoffice/program/libsal.so.3[0x40bddc96] /lib/libpthread.so.0[0x41146695] /lib/libc.so.6[0x41350578] /usr/lib/openoffice/program/libsal.so.3(osl_acquireMutex+0x28)[0x40bd29f3] /usr/lib/openoffice/program/libodbcbase2.so(_ZN12connectivity4odbc10OResultSet12getStatementEv+0x2b)[0x4625fec3] /usr/lib/openoffice/program/libodbcbase2.so(_ZN12connectivity4odbc17ODatabaseMetaDataC1ElPNS0_11OConnectionE+0xed)[0x4627720d] /usr/lib/openoffice/program/libodbcbase2.so(_ZN12connectivity4odbc11OConnection11getMetaDataEv+0x14a)[0x46289430] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cdb65] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cdf00] /usr/lib/openoffice/program/libgcc3_uno.so[0x445ce3c2] /usr/lib/openoffice/program/proxyfac.uno.so[0x448de6e9] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cb33a] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cb8de] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cba13] /usr/lib/openoffice/program/libdbpool2.so[0x461e8edb] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cdb65] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cdf00] /usr/lib/openoffice/program/libgcc3_uno.so[0x445ce3c2] /usr/lib/openoffice/program/proxyfac.uno.so[0x448de6e9] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cb33a] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cb8de] /usr/lib/openoffice/program/libgcc3_uno.so[0x445cba13] /usr/lib/openoffice/program/libdba645li.so[0x460e4a40] /usr/lib/openoffice/program/libdba645li.so[0x460e683d] /usr/lib/openoffice/program/libdba645li.so[0x460f61d4] /usr/lib/openoffice/program/libdba645li.so[0x460ed297] /usr/lib/openoffice/program/libdba645li.so[0x460f6414] /usr/lib/openoffice/program/libdba645li.so[0x460f5ff1] /usr/lib/openoffice/program/libdba645li.so[0x460f5814] /usr/lib/openoffice/program/libdbu645li.so[0x45c2b2c8] /usr/lib/openoffice/program/libdbu645li.so[0x45d08bf2] /usr/lib/openoffice/program/libdbu645li.so[0x45d68e9b] /usr/lib/openoffice/program/libdbu645li.so[0x45d68b8a] /usr/lib/openoffice/program/libdbu645li.so[0x45d621bd] /usr/lib/openoffice/program/libdbu645li.so[0x45d620ee] /usr/lib/openoffice/program/libdbu645li.so[0x45d7e68b] /usr/lib/openoffice/program/libsvt645li.so(_ZN13SvTreeListBox6ExpandEP11SvLBoxEntry+0x3f)[0x407c0fc5] /usr/lib/openoffice/program/libsvt645li.so(_ZN9SvImpLBox21ButtonDownCheckExpandERK10MouseEventP11SvLBoxEntryl+0xa6)[0x407b8e72] /usr/lib/openoffice/program/libsvt645li.so(_ZN9SvImpLBox15MouseButtonDownERK10MouseEvent+0xdd)[0x407b8f65] /usr/lib/openoffice/program/libsvt645li.so(_ZN13SvTreeListBox15MouseButtonDownERK10MouseEvent+0x2c)[0x407c169e] /usr/lib/openoffice/program/libdbu645li.so[0x45d7e9d2] /usr/lib/openoffice/program/libvcl645li.so(_Z20ImplHandleMouseEventP6Windowthllmtt+0xfef)[0x40227c21] /usr/lib/openoffice/program/libvcl645li.so(_Z19ImplWindowFrameProcPvP8SalFrametPKv+0xc8)[0x4022a4a4] /usr/lib/openoffice/program/libvcl645li.so(_ZN12SalFrameData16HandleMouseEventEP7_XEvent+0x46a)[0x40289e2e] /usr/lib/openoffice/program/libvcl645li.so(_ZN12SalFrameData8DispatchEP7_XEvent+0x137)[0x4028bd69] /usr/lib/openoffice/program/libvcl645li.so(_ZN10SalDisplay8DispatchEP7_XEvent+0x29a)[0x402b7bd2] /usr/lib/openoffice/program/libvcl645li.so(_ZN10SalDisplay5YieldEh+0xf1)[0x402b7915] /usr/lib/openoffice/program/libvcl645li.so[0x402b36a1] /usr/lib/openoffice/program/libvcl645li.so(_ZN7SalXLib5YieldEh+0x427)[0x402b2253] /usr/lib/openoffice/program/libvcl645li.so(_ZN11SalInstance5YieldEh+0x34)[0x402bb1ac] /usr/lib/openoffice/program/libvcl645li.so(_ZN11Application5YieldEv+0x61)[0x400e1e4b] /usr/lib/openoffice/program/libvcl645li.so(_ZN11Application7ExecuteEv+0x35)[0x400e1d5d] /usr/lib/openoffice/program/soffice.bin(_ZN7desktop7Desktop4MainEv+0x1ad7)[0x8064f71] /usr/lib/openoffice/program/libvcl645li.so(_Z6SVMainv+0x49)[0x400e69f7] /usr/lib/openoffice/program/libvcl645li.so(main+0x4c)[0x402b0be0] /lib/libc.so.6(__libc_start_main+0xce)[0x4133cdbe] /usr/lib/openoffice/program/soffice.bin(_ZN6Window11RequestHelpERK9HelpEvent+0x39)[0x805e331] zsh: abort ./scalc [root@potato:/usr/lib/openoffice/program]
This seems to be an unknown bug. The best way to get a chance to know what is going wrong here would be to send the crash report. This way we have the whole call stack and may be find the reason for the GPF. Thanks. Ocke
Set target to OO Later until we got some more information.
Created attachment 11183 [details] Crashreporter report from bug submitter
Do you know if the bug submitter send the crash report with the tool appearing? If yes, did he add an email or a description I can search for? The stack trace doesn't contain the methods called. Only the lib included. Best regards, Ocke
From: William Thompson <wt@electro-mechanical.com> To: Chris Halls, 219450-quiet@bugs.debian.org Subject: Re: Bug#219450: [Fwd: [Issue 22232] - Crash on connect, ODBC/FreeTDS/MSSQL7] Date: Wed, 12 Nov 2003 08:05:51 -0500 I did use the tool and I did give this email address. The information Iemailed to you/dbts is the information that the crash program gave me when Isent the report.
I found the crash report and change the target. Thanks. Ocke
.
It's a driver bug, when calling SQLGetInfo for SQL_FILE_USAGE, they write their value in a unsigned interger which should be by definition of ODBC a usigned small integer. This leads to the GPF.
The bug is fixed in the FreeTDS driver (cvs version). I set this one to invalid, because the bug doesn't occur inside the OpenOffice.org source code. @see " >> >> Hi all, >> >> I encounter a bug in the function SQLGetInfo. When asking for >> SQL_FILE_USAGE, the return value is inserted into a >> SQL_UINTEGER which >> overwrites some stack variables since the type for >> SQL_DFILE_USAGE is a >> SQL_USMALLINT. This leads to GPF when using it with OpenOffice.org. >> >> For a brief discussion please have a look at >> http://www.openoffice.org/issues/show_bug.cgi?id=22232&frame=true >> >> Best regards, >> >> Ocke >> >> PS: I don't know if this is the only one >> Fixed. Noted that 0.62 version (current CVS) do not have the bug... freddy77 _______________________________________________ FreeTDS mailing list FreeTDS@lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds "
change subcomponent to 'none'