You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Herbert Duerr <hd...@apache.org> on 2014/02/01 13:45:44 UTC
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; api@openoffice.apache.org; Herbert Duerr (hdu@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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Thanks. An enlightenment would be great, but I am afraid that may not happen. :)
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Monday, February 17, 2014 3:27 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 14.02.2014 22:37, Steele, Raymond wrote:
Andre,
I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime?
Not big. It is probably OK to move on and come back later when you have some sort of enlightenment.
-Andre
We are working on the Save now (described below).
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Friday, February 07, 2014 2:18 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 07.02.2014 00:04, Steele, Raymond wrote:
Andre,
When we commented out the section below, we were able to get the application to work correctly
I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows.
(although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif).
Strange, this change should not modify the saving of the document. That is probably an unrelated problem.
However, the application crashes when we replace the lines with:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.
Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference<...>::iquery. And boost::scoped_ptr<Window> should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered.
All this looks like the actual problem happens earlier, maybe some memory overwrite.
Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem?
Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.?
No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash.
And, no, I am not located in the US. I am in Germany.
-Andre
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; awf.aoo@gmail.com<ma...@gmail.com>
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Raymond,
there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed.
In my case it is 3.
-Andre
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org<ma...@openoffice.apache.org>'; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; 'awf.aoo@gmail.com<ma...@gmail.com>'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire() Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & rxFrame) Line 168 + 0x12 bytes C++
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 14.02.2014 22:37, Steele, Raymond wrote:
>
> Andre,
>
> I think we are going to keep that section commented out for now. We
> are not sure what to do. Do you think commenting out that section will
> have a big impact at runtime?
>
Not big. It is probably OK to move on and come back later when you have
some sort of enlightenment.
-Andre
> We are working on the Save now (described below).
>
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Friday, February 07, 2014 2:18 AM
> *To:* Steele, Raymond; Andre Fischer; api@openoffice.apache.org;
> Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
> *Cc:* Meffe, David K
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 07.02.2014 00:04, Steele, Raymond wrote:
>
> Andre,
>
> When we commented out the section below, we were able to get the
> application to work correctly
>
>
> I would expect subtle errors in the sidebar, like panels not updating
> after context changes or when switching between application windows.
>
>
> (although it did not let us save a spreadsheet to disk for some
> reason. Each time we hit okay to save after supplying a unique name,
> the filechooser closes, but instantly reappears again. It did let us
> save it as another format, such as .dif).
>
>
> Strange, this change should not modify the saving of the document.
> That is probably an unrelated problem.
>
>
> However, the application crashes when we replace the lines with:
>
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
>
> I've attached the stack trace of that crash. It crashes right after
> the SidebarController destructor on line 177 (which is empty).
> Stepping from the destructor brings us into boost's
> checked_delete.hpp and eventually crashes at line 34 "delete x". See
> attached stack trace. m_RefCount was 3 for us as well.
>
>
> Also strange. All this does not fit together. If the ref count is
> larger than 0 then the SidebarController should not be deleted. And
> if it where deleted, then not from Reference<...>::iquery. And
> boost::scoped_ptr<Window> should have no problem deleting the control
> (I have not enough information to say which one it is). All controls
> are created in the initializer of the constructor and should be fully
> created and initialized by the time the crash is triggered.
>
> All this looks like the actual problem happens earlier, maybe some
> memory overwrite.
>
> Maybe you can use valgrind (or some other memory checker) to see if
> there is a memory problem?
>
>
> Thanks for taking the time to look into this, we are grateful. Would
> you happen to be located in the U.S.?
>
>
> No problem. I am a little worried that you have discovered a problem
> that lurks on all platforms and Solaris is the only one where it leads
> to an actual crash.
>
> And, no, I am not located in the US. I am in Germany.
>
> -Andre
>
>
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Thursday, February 06, 2014 2:03 AM
> *To:* Steele, Raymond; api@openoffice.apache.org
> <ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org
> <ma...@apache.org>); dev@openoffice.apache.org
> <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; awf.aoo@gmail.com <ma...@gmail.com>
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I
> am not looking in the right place, but we've been using dbx
> intercept command to track any. Any other suggestions?
>
>
> Raymond,
>
> there a few thing you can do to find out if this is a local problem
> (broken in the constructor) or something more fundamental that is
> possibly caused by an error that happened much earlier.
>
> - Comment out the last few lines:
> /*
> WeakReference<SidebarController> xWeakController (this);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> */
> That should tell us whether the crash is caused just by storing the
> weak reference.
> The sidebar should still work in general but some updates may be lost.
>
> - Replace the last few lines by this:
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> That removes one (of two) acquire calls (I don't know yet why there is
> a second acquire, after all the purpose of the weak reference is just
> /not/ to increase the reference count).
>
> - Check the value of the reference count of 'SidebarController* this'
> (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
> the SidebarController constructor is executed.
> In my case it is 3.
>
> -Andre
>
>
>
>
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
>
> That is OK. They should be different. But the stack trace of the
> second call looks broken. The top two frames
> (notifyContextChangeEvent being called from Reference constructor)
> indicate that something is very wrong, like the vtable overwritten or
> not fully created. One explanation (although I cannot say how
> probable that is) could be that the Solaris compiler has not fully
> created/initialized the vtable in the constructor.
>
>
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org <ma...@openoffice.apache.org>';
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com <ma...@gmail.com>'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
>
> Here are the requested frames
>
> > cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
> cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line
> 236 + 0x9 bytes C++
> sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
> Line 70 + 0xc bytes C++
> sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
> * pInterface) Line 136 + 0x12 bytes C++
> sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
> * pParentWindow, const
> com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
> rxFrame) Line 168 + 0x12 bytes C++
>
>
>
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 14.02.2014 22:37, Steele, Raymond wrote:
>
> Andre,
>
> I think we are going to keep that section commented out for now. We
> are not sure what to do. Do you think commenting out that section will
> have a big impact at runtime?
>
Not big. It is probably OK to move on and come back later when you have
some sort of enlightenment.
-Andre
> We are working on the Save now (described below).
>
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Friday, February 07, 2014 2:18 AM
> *To:* Steele, Raymond; Andre Fischer; api@openoffice.apache.org;
> Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
> *Cc:* Meffe, David K
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 07.02.2014 00:04, Steele, Raymond wrote:
>
> Andre,
>
> When we commented out the section below, we were able to get the
> application to work correctly
>
>
> I would expect subtle errors in the sidebar, like panels not updating
> after context changes or when switching between application windows.
>
>
> (although it did not let us save a spreadsheet to disk for some
> reason. Each time we hit okay to save after supplying a unique name,
> the filechooser closes, but instantly reappears again. It did let us
> save it as another format, such as .dif).
>
>
> Strange, this change should not modify the saving of the document.
> That is probably an unrelated problem.
>
>
> However, the application crashes when we replace the lines with:
>
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
>
> I've attached the stack trace of that crash. It crashes right after
> the SidebarController destructor on line 177 (which is empty).
> Stepping from the destructor brings us into boost's
> checked_delete.hpp and eventually crashes at line 34 "delete x". See
> attached stack trace. m_RefCount was 3 for us as well.
>
>
> Also strange. All this does not fit together. If the ref count is
> larger than 0 then the SidebarController should not be deleted. And
> if it where deleted, then not from Reference<...>::iquery. And
> boost::scoped_ptr<Window> should have no problem deleting the control
> (I have not enough information to say which one it is). All controls
> are created in the initializer of the constructor and should be fully
> created and initialized by the time the crash is triggered.
>
> All this looks like the actual problem happens earlier, maybe some
> memory overwrite.
>
> Maybe you can use valgrind (or some other memory checker) to see if
> there is a memory problem?
>
>
> Thanks for taking the time to look into this, we are grateful. Would
> you happen to be located in the U.S.?
>
>
> No problem. I am a little worried that you have discovered a problem
> that lurks on all platforms and Solaris is the only one where it leads
> to an actual crash.
>
> And, no, I am not located in the US. I am in Germany.
>
> -Andre
>
>
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Thursday, February 06, 2014 2:03 AM
> *To:* Steele, Raymond; api@openoffice.apache.org
> <ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org
> <ma...@apache.org>); dev@openoffice.apache.org
> <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; awf.aoo@gmail.com <ma...@gmail.com>
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I
> am not looking in the right place, but we've been using dbx
> intercept command to track any. Any other suggestions?
>
>
> Raymond,
>
> there a few thing you can do to find out if this is a local problem
> (broken in the constructor) or something more fundamental that is
> possibly caused by an error that happened much earlier.
>
> - Comment out the last few lines:
> /*
> WeakReference<SidebarController> xWeakController (this);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> */
> That should tell us whether the crash is caused just by storing the
> weak reference.
> The sidebar should still work in general but some updates may be lost.
>
> - Replace the last few lines by this:
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> That removes one (of two) acquire calls (I don't know yet why there is
> a second acquire, after all the purpose of the weak reference is just
> /not/ to increase the reference count).
>
> - Check the value of the reference count of 'SidebarController* this'
> (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
> the SidebarController constructor is executed.
> In my case it is 3.
>
> -Andre
>
>
>
>
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
>
> That is OK. They should be different. But the stack trace of the
> second call looks broken. The top two frames
> (notifyContextChangeEvent being called from Reference constructor)
> indicate that something is very wrong, like the vtable overwritten or
> not fully created. One explanation (although I cannot say how
> probable that is) could be that the Solaris compiler has not fully
> created/initialized the vtable in the constructor.
>
>
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org <ma...@openoffice.apache.org>';
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com <ma...@gmail.com>'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
>
> Here are the requested frames
>
> > cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
> cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line
> 236 + 0x9 bytes C++
> sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
> Line 70 + 0xc bytes C++
> sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
> * pInterface) Line 136 + 0x12 bytes C++
> sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
> * pParentWindow, const
> com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
> rxFrame) Line 168 + 0x12 bytes C++
>
>
>
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime?
We are working on the Save now (described below).
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Friday, February 07, 2014 2:18 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 07.02.2014 00:04, Steele, Raymond wrote:
Andre,
When we commented out the section below, we were able to get the application to work correctly
I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows.
(although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif).
Strange, this change should not modify the saving of the document. That is probably an unrelated problem.
However, the application crashes when we replace the lines with:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.
Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference<...>::iquery. And boost::scoped_ptr<Window> should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered.
All this looks like the actual problem happens earlier, maybe some memory overwrite.
Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem?
Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.?
No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash.
And, no, I am not located in the US. I am in Germany.
-Andre
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; awf.aoo@gmail.com<ma...@gmail.com>
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Raymond,
there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed.
In my case it is 3.
-Andre
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org<ma...@openoffice.apache.org>'; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; 'awf.aoo@gmail.com<ma...@gmail.com>'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire() Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & rxFrame) Line 168 + 0x12 bytes C++
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime?
We are working on the Save now (described below).
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Friday, February 07, 2014 2:18 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 07.02.2014 00:04, Steele, Raymond wrote:
Andre,
When we commented out the section below, we were able to get the application to work correctly
I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows.
(although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif).
Strange, this change should not modify the saving of the document. That is probably an unrelated problem.
However, the application crashes when we replace the lines with:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.
Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference<...>::iquery. And boost::scoped_ptr<Window> should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered.
All this looks like the actual problem happens earlier, maybe some memory overwrite.
Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem?
Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.?
No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash.
And, no, I am not located in the US. I am in Germany.
-Andre
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; awf.aoo@gmail.com<ma...@gmail.com>
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Raymond,
there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed.
In my case it is 3.
-Andre
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org<ma...@openoffice.apache.org>'; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; 'awf.aoo@gmail.com<ma...@gmail.com>'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire() Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & rxFrame) Line 168 + 0x12 bytes C++
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 07.02.2014 00:04, Steele, Raymond wrote:
>
> Andre,
>
> When we commented out the section below, we were able to get the
> application to work correctly
>
I would expect subtle errors in the sidebar, like panels not updating
after context changes or when switching between application windows.
> (although it did not let us save a spreadsheet to disk for some
> reason. Each time we hit okay to save after supplying a unique name,
> the filechooser closes, but instantly reappears again. It did let us
> save it as another format, such as .dif).
>
Strange, this change should not modify the saving of the document. That
is probably an unrelated problem.
> However, the application crashes when we replace the lines with:
>
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
>
> I've attached the stack trace of that crash. It crashes right after
> the SidebarController destructor on line 177 (which is empty).
> Stepping from the destructor brings us into boost's
> checked_delete.hpp and eventually crashes at line 34 "delete x". See
> attached stack trace. m_RefCount was 3 for us as well.
>
Also strange. All this does not fit together. If the ref count is
larger than 0 then the SidebarController should not be deleted. And if
it where deleted, then not from Reference<...>::iquery. And
boost::scoped_ptr<Window> should have no problem deleting the control (I
have not enough information to say which one it is). All controls are
created in the initializer of the constructor and should be fully
created and initialized by the time the crash is triggered.
All this looks like the actual problem happens earlier, maybe some
memory overwrite.
Maybe you can use valgrind (or some other memory checker) to see if
there is a memory problem?
> Thanks for taking the time to look into this, we are grateful. Would
> you happen to be located in the U.S.?
>
No problem. I am a little worried that you have discovered a problem
that lurks on all platforms and Solaris is the only one where it leads
to an actual crash.
And, no, I am not located in the US. I am in Germany.
-Andre
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Thursday, February 06, 2014 2:03 AM
> *To:* Steele, Raymond; api@openoffice.apache.org; Herbert Duerr
> (hdu@apache.org); dev@openoffice.apache.org
> *Cc:* Meffe, David K; awf.aoo@gmail.com
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I
> am not looking in the right place, but we've been using dbx
> intercept command to track any. Any other suggestions?
>
>
> Raymond,
>
> there a few thing you can do to find out if this is a local problem
> (broken in the constructor) or something more fundamental that is
> possibly caused by an error that happened much earlier.
>
> - Comment out the last few lines:
> /*
> WeakReference<SidebarController> xWeakController (this);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> */
> That should tell us whether the crash is caused just by storing the
> weak reference.
> The sidebar should still work in general but some updates may be lost.
>
> - Replace the last few lines by this:
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> That removes one (of two) acquire calls (I don't know yet why there is
> a second acquire, after all the purpose of the weak reference is just
> /not/ to increase the reference count).
>
> - Check the value of the reference count of 'SidebarController* this'
> (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
> the SidebarController constructor is executed.
> In my case it is 3.
>
> -Andre
>
>
>
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
>
> That is OK. They should be different. But the stack trace of the
> second call looks broken. The top two frames
> (notifyContextChangeEvent being called from Reference constructor)
> indicate that something is very wrong, like the vtable overwritten or
> not fully created. One explanation (although I cannot say how
> probable that is) could be that the Solaris compiler has not fully
> created/initialized the vtable in the constructor.
>
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org <ma...@openoffice.apache.org>';
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com <ma...@gmail.com>'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
>
> Here are the requested frames
>
> > cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
> cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line
> 236 + 0x9 bytes C++
> sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
> Line 70 + 0xc bytes C++
> sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
> * pInterface) Line 136 + 0x12 bytes C++
> sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
> * pParentWindow, const
> com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
> rxFrame) Line 168 + 0x12 bytes C++
>
>
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 07.02.2014 00:04, Steele, Raymond wrote:
>
> Andre,
>
> When we commented out the section below, we were able to get the
> application to work correctly
>
I would expect subtle errors in the sidebar, like panels not updating
after context changes or when switching between application windows.
> (although it did not let us save a spreadsheet to disk for some
> reason. Each time we hit okay to save after supplying a unique name,
> the filechooser closes, but instantly reappears again. It did let us
> save it as another format, such as .dif).
>
Strange, this change should not modify the saving of the document. That
is probably an unrelated problem.
> However, the application crashes when we replace the lines with:
>
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
>
> I've attached the stack trace of that crash. It crashes right after
> the SidebarController destructor on line 177 (which is empty).
> Stepping from the destructor brings us into boost's
> checked_delete.hpp and eventually crashes at line 34 "delete x". See
> attached stack trace. m_RefCount was 3 for us as well.
>
Also strange. All this does not fit together. If the ref count is
larger than 0 then the SidebarController should not be deleted. And if
it where deleted, then not from Reference<...>::iquery. And
boost::scoped_ptr<Window> should have no problem deleting the control (I
have not enough information to say which one it is). All controls are
created in the initializer of the constructor and should be fully
created and initialized by the time the crash is triggered.
All this looks like the actual problem happens earlier, maybe some
memory overwrite.
Maybe you can use valgrind (or some other memory checker) to see if
there is a memory problem?
> Thanks for taking the time to look into this, we are grateful. Would
> you happen to be located in the U.S.?
>
No problem. I am a little worried that you have discovered a problem
that lurks on all platforms and Solaris is the only one where it leads
to an actual crash.
And, no, I am not located in the US. I am in Germany.
-Andre
> *From:*Andre Fischer [mailto:awf.aoo@gmail.com]
> *Sent:* Thursday, February 06, 2014 2:03 AM
> *To:* Steele, Raymond; api@openoffice.apache.org; Herbert Duerr
> (hdu@apache.org); dev@openoffice.apache.org
> *Cc:* Meffe, David K; awf.aoo@gmail.com
> *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I
> am not looking in the right place, but we've been using dbx
> intercept command to track any. Any other suggestions?
>
>
> Raymond,
>
> there a few thing you can do to find out if this is a local problem
> (broken in the constructor) or something more fundamental that is
> possibly caused by an error that happened much earlier.
>
> - Comment out the last few lines:
> /*
> WeakReference<SidebarController> xWeakController (this);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> */
> That should tell us whether the crash is caused just by storing the
> weak reference.
> The sidebar should still work in general but some updates may be lost.
>
> - Replace the last few lines by this:
> Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
> WeakReference<SidebarController> xWeakController (xThis);
> maSidebarControllerContainer.insert(
> SidebarControllerContainer::value_type(
> rxFrame,
> xWeakController));
> That removes one (of two) acquire calls (I don't know yet why there is
> a second acquire, after all the purpose of the weak reference is just
> /not/ to increase the reference count).
>
> - Check the value of the reference count of 'SidebarController* this'
> (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
> the SidebarController constructor is executed.
> In my case it is 3.
>
> -Andre
>
>
>
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
>
> That is OK. They should be different. But the stack trace of the
> second call looks broken. The top two frames
> (notifyContextChangeEvent being called from Reference constructor)
> indicate that something is very wrong, like the vtable overwritten or
> not fully created. One explanation (although I cannot say how
> probable that is) could be that the Solaris compiler has not fully
> created/initialized the vtable in the constructor.
>
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org <ma...@openoffice.apache.org>';
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com <ma...@gmail.com>'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
>
> Here are the requested frames
>
> > cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
> cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line
> 236 + 0x9 bytes C++
> sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
> Line 70 + 0xc bytes C++
> sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
> * pInterface) Line 136 + 0x12 bytes C++
> sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
> * pParentWindow, const
> com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
> rxFrame) Line 168 + 0x12 bytes C++
>
>
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
When we commented out the section below, we were able to get the application to work correctly (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif).
However, the application crashes when we replace the lines with:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.
Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.?
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; awf.aoo@gmail.com
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Raymond,
there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed.
In my case it is 3.
-Andre
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org<ma...@openoffice.apache.org>'; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; 'awf.aoo@gmail.com<ma...@gmail.com>'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire() Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & rxFrame) Line 168 + 0x12 bytes C++
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
When we commented out the section below, we were able to get the application to work correctly (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif).
However, the application crashes when we replace the lines with:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.
Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.?
From: Andre Fischer [mailto:awf.aoo@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; awf.aoo@gmail.com
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Raymond,
there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed.
In my case it is 3.
-Andre
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org<ma...@openoffice.apache.org>'; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K; 'awf.aoo@gmail.com<ma...@gmail.com>'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire() Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & rxFrame) Line 168 + 0x12 bytes C++
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I am
> not looking in the right place, but we've been using dbx intercept
> command to track any. Any other suggestions?
>
Raymond,
there a few thing you can do to find out if this is a local problem
(broken in the constructor) or something more fundamental that is
possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak
reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a
second acquire, after all the purpose of the weak reference is just
/not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this'
(in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
the SidebarController constructor is executed.
In my case it is 3.
-Andre
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
That is OK. They should be different. But the stack trace of the
second call looks broken. The top two frames (notifyContextChangeEvent
being called from Reference constructor) indicate that something is very
wrong, like the vtable overwritten or not fully created. One
explanation (although I cannot say how probable that is) could be that
the Solaris compiler has not fully created/initialized the vtable in the
constructor.
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org'; Herbert Duerr (hdu@apache.org);
> dev@openoffice.apache.org
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236
+ 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
* pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
* pParentWindow, const
com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
rxFrame) Line 168 + 0x12 bytes C++
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
On 05.02.2014 20:02, Steele, Raymond wrote:
>
> Andre,
>
> We are not seeing any exception before the actual crash. Maybe I am
> not looking in the right place, but we've been using dbx intercept
> command to track any. Any other suggestions?
>
Raymond,
there a few thing you can do to find out if this is a local problem
(broken in the constructor) or something more fundamental that is
possibly caused by an error that happened much earlier.
- Comment out the last few lines:
/*
WeakReference<SidebarController> xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
*/
That should tell us whether the crash is caused just by storing the weak
reference.
The sidebar should still work in general but some updates may be lost.
- Replace the last few lines by this:
Reference<SidebarController> xThis (this, SAL_NO_ACQUIRE);
WeakReference<SidebarController> xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a
second acquire, after all the purpose of the weak reference is just
/not/ to increase the reference count).
- Check the value of the reference count of 'SidebarController* this'
(in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of
the SidebarController constructor is executed.
In my case it is 3.
-Andre
> Also, I've attached the stack trace of the first and second
> notifyContextChangeEvent. They are different.
>
That is OK. They should be different. But the stack trace of the
second call looks broken. The top two frames (notifyContextChangeEvent
being called from Reference constructor) indicate that something is very
wrong, like the vtable overwritten or not fully created. One
explanation (although I cannot say how probable that is) could be that
the Solaris compiler has not fully created/initialized the vtable in the
constructor.
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Wednesday, February 05, 2014 9:48 AM
> *To:* 'api@openoffice.apache.org'; Herbert Duerr (hdu@apache.org);
> dev@openoffice.apache.org
> *Cc:* Meffe, David K; 'awf.aoo@gmail.com'
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> Hi Andre,
>
> Thanks for the response. We are looking at that now.
>
> In the constructor of SidebarController at line 168
> "WeakReference...", on your system, does the code step to
> Reference.h: Line 359 -- XInterface operator, as it does during our run?
>
> It appears that at runtime Reference.hxx: Line 136 -
> _pInterface->acquire() that occurs after "WeakReference.." does not
> execute as it does after addContextChangeEventListener a few lines
> above WeakReference. Do you see a similar behavior? Can you provide
> the first 5-10 steps your code takes after WeakReference (line 168)?
>
Here are the requested frames
> cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236
+ 0x9 bytes C++
sfx.dll!cppu::WeakComponentImplHelper4<com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener>::acquire()
Line 70 + 0xc bytes C++
sfx.dll!com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference<sfx2::sidebar::SidebarController>(sfx2::sidebar::SidebarController
* pInterface) Line 136 + 0x12 bytes C++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
* pParentWindow, const
com::sun::star::uno::Reference<com::sun::star::frame::XFrame> &
rxFrame) Line 168 + 0x12 bytes C++
> Thanks!
>
> Raymond
>
> *From:*Steele, Raymond
> *Sent:* Tuesday, February 04, 2014 3:59 PM
> *To:* api@openoffice.apache.org <ma...@openoffice.apache.org>;
> Herbert Duerr (hdu@apache.org <ma...@apache.org>);
> dev@openoffice.apache.org <ma...@openoffice.apache.org>
> *Cc:* Meffe, David K
> *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86
> Runtime Memory Fault
>
> 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.
>
> 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:
>
> 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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@openoffice.apache.org <ma...@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 <ma...@openoffice.apache.org>;
> api@openoffice.apache.org <ma...@openoffice.apache.org>; Herbert
>
> > Duerr (hdu@apache.org <ma...@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-unsubscribe@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org
> <ma...@openoffice.apache.org>
>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org'; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; 'awf.aoo@gmail.com'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory
Fault
Posted by Andre Fischer <aw...@gmail.com>.
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:hdu@apache.org]
> Sent: Saturday, February 01, 2014 5:46 AM
> To: api@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
>> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
>
> For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
Andre,
We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions?
Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different.
Raymond
From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org'; Herbert Duerr (hdu@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; 'awf.aoo@gmail.com'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre,
Thanks for the response. We are looking at that now.
In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run?
It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)?
Thanks!
Raymond
From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert Duerr (hdu@apache.org<ma...@apache.org>); dev@openoffice.apache.org<ma...@openoffice.apache.org>
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<ma...@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime
Memory Fault
Posted by "Steele, Raymond" <ra...@lmco.com>.
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.
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:
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:hdu@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@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<ma...@openoffice.apache.org>; api@openoffice.apache.org<ma...@openoffice.apache.org>; Herbert
> Duerr (hdu@apache.org<ma...@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-unsubscribe@openoffice.apache.org<ma...@openoffice.apache.org>
For additional commands, e-mail: api-help@openoffice.apache.org<ma...@openoffice.apache.org>