Hi David,
I just wanted to share the basics of what I have found so far. I still have no
idea on how to solve the issue. Any help would be great!
Observed Behaviour
1. OpenOffice starts, the splash screen with logo appears and then closes
replaced with the full application window and choices for specific OpenOffice
projects.
2. Selecting either the Word or Spreadsheet project causes a segmentation
fault and closes the application.
3. Following the start of the application with the debugger, we can see
the SidebarController is created in a first pass without error (known because
first time to this stop point does not error).
4. As the process continues, the SidebarController constructor is called a
second time (unknown why, but could be understood with more familiarity with
the system).
5. The failure doesn't appear in the constructor, but the trace follows down
SidebarController constructor call of "WeakReference<SidebarController>
WeakController (this);"
6. This template definition for WeakController uses
Reference<Template>::Refrence( interface_type *pInterface) as its definition in
::com::sun::star::uno::Reference.hxx.
7. The function will try to convert the pInterface parameter to a
XInterface type called _pInterface.
8. If it succeeds in converting the pInterface to _pInterface then the
function will try to acquire a new reference.
9. Assumption: Creating this new reference calls
SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This
assumption is based on the stack where the immediate next routine after the Reference
function call is the notifyContextChangeEvent, also while following along in the
debugger, the rEvent parameter at this point is already corrupted with the value
<ERROR> stored in the structure.
10. It is later after the notifyContextChangeEvent calls Context and then
ustring that the segmentation fault occurs, but I believe the error located in
rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this
I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use
the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
