On 04.02.2014 23:58, Steele, Raymond wrote:
Herbert,
Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3
with an equivalent throw/catch feature (intercept/whocatches) and have found
that the cases where we tried to intercept exceptions, they were unhandled.
This includes inside the SidebarController where we have tracked the problem
origination. We have stepped through the code multiple times and while we have
found that the problem originates in the SidebarController, we cannot explain
how it happens.
Hi, my name is Andre. I am the one who wrote the sidebar framework. I
don't know if I can help (I can not reproduce this problem on a platform
which I have access to) but I will try.
Which exceptions (before the actual crash) do you see?
Using the debug tool we see that the SidebarController constructor doesn't
complete because the segmentation fault occurs when the
notifyContextChangeEvent is called a second time. The first time it is called
it is located in the addContextChangeEventListener where it appears to work as
expected, even the acquire function appears to call the
ContextChangeEventMultiplexer without any errors.
The following lines are what we see as we step-by-step through the execution of
the SidebarController.cxx constructor when we select the Spreadsheet or the
Text Document.
The first time the notifyContextChangeEvent is called:
SidebarController: Line 147 - addContextChangeEventListener is called
Reference.h: Line 359 - XInterface operator -> is called
Reference.h: Line 217 - castFromXInterface is called
Reference.hxx: Line 134 - castToXInterface is called
Reference.h: Line 232 - function castToXInterface
Reference.hxx: Line 135 - if(_pInterface)
Reference.hxx: Line 136 - _pInterface->acquire();
compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype
implbase.hxx: Line 236 - WeakObject::acquire definition
- ContextChangeEventMultiplexer receives and processes event.
- In ContextChangeEventMultiplexer addContextChangeEventListener
adds and calls the notifyContextChangeEvent
- SidebarController::notifyContextChangeEvent: Line 257 is called.
The rEvent associated with the notifyContextChangeEvent is a valid address
- The rEvent STRUCT contains the application name and context name
references
Context.cxx: Line 51 - msContext(rsContext)
ustring.hxx: Line103 - pData = str.pData
- Processing continues as normal from this point till line 168 of
SidebarController.cxx
The second time the notifyContextChangeEvent is called:
I checked what is happening on Windows:
- there should be exactly one call to the SidebarController constructor
per application window. The constructor is called from the
SidebarDockingWindow constructor. A second call, as described in your
earlier mail should not take place. Can you check the stack trace of
that second call and see who makes that call?
- While in the constructor of SidebarController I see only one call to
notifyContextChangeEvent(). As you found out it is triggered by the
SidebarController registering itself as listener (it is being informed
of the current context). The second call (while inside the constructor)
is not necessarily an error but I would like to know what triggers it.
The second call that I see is triggered after the SidebarController is
constructed and is made (indirectly) from SfxViewFrame::DoActivate().
Can you show me the stack trace of that second call?
SidebarController: Line 168 - the xWeakController(this) is called
Reference.hxx: Line 134 - castToXInterface is called
Reference.h: Line 232 - function castToXInterface
Reference.hxx: Line 135 - if(_pInterface)
Reference.hxx: Line 136 - _pInterface->acquire(); (Why does this not behave
like the first call above? Should there be a call to
WeakComponentHelperBase::acuire? The next step appears to skip all these
procedures.)
SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is
pointing to a reference that cannot be accessed.
- The dbx dump has an rEvent = STRUCT
- The dbx print of the rEvent says that it is referenced through a
nil pointer
Context.cxx: Line 51 - msContext(rsContext)
ustring.hxx: Line103 - pData = str.pData
- Accessing the pData in the string has been corrupted and causes
the following Segmentation Fault:
- Signal SEGV(no mapping at the fault address) in
rtl::OUString::OUString at line 103 in file ustring.hxx
We are trying to do our due diligence on this problem and we have been
investigating it as best we can, but we are lacking in knowledge that the
community can provide, which is why we are seeking help. Also the errors don't
seem to make sense, so we believe we are dealing with a bug. We hope we are not
being an inconvenience, and we definitely appreciate the help. We are
investigating alternatives, but would really like to get this to work. Our
current applications use OpenOffice extensively. Since we had to move to
Solaris 11, we are forced to get this working or find another solution, which
we'd rather not pursue.
Hopefully you or a member of the community can help us make some headway. We'd
appreciate it. Thanks.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: a...@openoffice.apache.org
Subject: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Raymond,
most regulars are traveling (and are meeting this weekend at FOSDEM in
Brussels).
I already recommended the try to find whether any exceptions are thrown (and
caught away) during the steps you already debugged.
In gdb I'd use the command
catch throw
to find the throwing code. Maybe there is similar facility in Solaris Studio?
Herbert
On 31.01.2014 20:27, Steele, Raymond wrote:
Anyone out there? We really need to get this working, but are having a
difficult time.
From: Steele, Raymond
Sent: Wednesday, January 29, 2014 5:11 PM
To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org>;
a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>; Herbert
Duerr (h...@apache.org<mailto:h...@apache.org>)
Cc: Meffe, David K
Subject: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are experiencing
the following at runtime. I've included some of the stack trace below. Any help
would be great. Thanks!
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.
It appears as if inside the SidebarController Constructor at line 168
when xWeakController(this) is called that the problem first occurs.
The xWeakController appears to be defined in Reference.hxx in
/cppu/inc/com/sun/star/uno/ and this definition as an inline function
that calls the _pInterface->acquire() at line 136. We assume that this
acquire is where the problem occurs because the
SidebarController::notifyContextChangeEvent (which is the next item on
the stack) rEvent contains an <ERROR> value in the dbxtool (debug
tool) immediately following in the stack. It eventually crashes
downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string
is trying to be accessed as pData = str.pData;
Stack Trace:
(dbx) where
current thread: t@1
=>[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in
"ustring.hxx"
[2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = CLASS,
rsContext = CLASS), line 51 in "Context.cxx"
[3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 0xebc6d6b0,
rEvent = STRUCT), line 257 in "SideBarController.cxx"
[4]
com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference(this =
0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in "Reference.hxx"
[5] sfx2::sidebar::SidebarController::SidebarController(this = 0xebc6d6b0,
pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in "SidebarController.cxx"
I can provide more of the stack trace if needed. Thanks in Advance!
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail:
api-unsubscr...@openoffice.apache.org<mailto:api-unsubscr...@openoffice.apache.org>
For additional commands, e-mail:
api-h...@openoffice.apache.org<mailto:api-h...@openoffice.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
