To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=110236
User mst changed the following:
What |Old value |New value
================================================================================
CC|'' |'fs,mst,sb'
--------------------------------------------------------------------------------
------- Additional comments from [email protected] Wed Mar 31 12:18:08 +0000
2010 -------
relevant lines from the stack seem to be:
#18 0x0804922e in operator delete ()
#19 0xac4147fc in cow_SQLDriverConnect ()
from /opt/ibm/iSeriesAccess/lib/libcwbodbc.so
#20 0xac3f8fef in SQLDriverConnect ()
from /opt/ibm/iSeriesAccess/lib/libcwbodbc.so
#21 0xac444439 in SQLDriverConnect () from /usr/lib/libodbc.so.1
#22 0xac51c0e2 in connectivity::odbc::OConnection::OpenConnection ()
from
/home/terry/OOo_hacking/localbuild/openoffice.org3/program/../basis-link/program/libodbcbaseli.so
so if this stack is to be trusted, then it seems to me that the memory
management error is actually in /opt/ibm/iSeriesAccess/lib/libcwbodbc.so, which
is (afaik) not a library shipped with OOo.
if this is indeed the case, you should close this issue, and report this to IBM.
but now i'm curious:
how can our sal library detect a memory management bug in some third party
library that was not linked against libuno_sal at all?
do we globally replace operator new/operator delete in the entire process?
how does that work without LD_PRELOAD?
let me guess.... if the binary itself contains the definition of operator
new/delete, then the ELF linker looks there first, and binds the symbols to that
definition even in libraries that are dl_opened later?
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
