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 (h...@apache.org); 
d...@openoffice.apache.org
Cc: Meffe, David K; 'awf....@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<mailto:api@openoffice.apache.org>; Herbert Duerr 
(h...@apache.org<mailto:h...@apache.org>); 
d...@openoffice.apache.org<mailto:d...@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:h...@apache.org]
Sent: Saturday, February 01, 2014 5:46 AM
To: api@openoffice.apache.org<mailto: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: d...@openoffice.apache.org<mailto:d...@openoffice.apache.org>; 
> api@openoffice.apache.org<mailto:api@openoffice.apache.org>; Herbert

> Duerr (h...@apache.org<mailto:h...@apache.org>)

> Cc: Meffe, David K

> Subject: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

>

>

> We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are 
> experiencing the following at runtime. I've included some of the stack trace 
> below. Any help would be great. Thanks!

>

>

>

> Observed Behaviour

>

> 1.            OpenOffice starts, the splash screen with logo appears and then 
> closes replaced with the full application window and choices for specific 
> OpenOffice projects.

>

> 2.            Selecting either the Word or Spreadsheet project causes a 
> segmentation fault and closes the application.

>

> 3.            Following the start of the application with the debugger, we 
> can see the SidebarController is created in a first pass without error (known 
> because first time to this stop point does not error).

>

> 4.            As the process continues, the SidebarController constructor is 
> called a second time (unknown why, but could be understood with more 
> familiarity with the system).

>

> 5.            The failure doesn't appear in the constructor, but the trace 
> follows down SidebarController constructor call of 
> "WeakReference<SidebarController> WeakController (this);"

>

> 6.            This template definition for WeakController uses 
> Reference<Template>::Refrence( interface_type *pInterface) as its definition 
> in ::com::sun::star::uno::Reference.hxx.

>

> 7.            The function will try to convert the pInterface parameter to a 
> XInterface type called _pInterface.

>

> 8.            If it succeeds in converting the pInterface to _pInterface then 
> the function will try to acquire a new reference.

>

> 9.            Assumption: Creating this new reference calls 
> SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. 
> This assumption is based on the stack where the immediate next routine after 
> the Reference function call is the notifyContextChangeEvent, also while 
> following along in the debugger, the rEvent parameter at this point is 
> already corrupted with the value <ERROR> stored in the structure.

>

> 10.          It is later after the notifyContextChangeEvent calls Context and 
> then ustring that the segmentation fault occurs, but I believe the error 
> located in rEvent is what causes this later problem.

>

>

>

> It appears as if inside the SidebarController Constructor at line 168

> when xWeakController(this) is called that the problem first occurs.

> The xWeakController appears to be  defined in Reference.hxx in

> /cppu/inc/com/sun/star/uno/ and this definition as an inline function

> that calls the _pInterface->acquire() at line 136. We assume that this

> acquire is where the problem occurs because the

> SidebarController::notifyContextChangeEvent (which is the next item on

> the stack) rEvent contains an <ERROR> value in the dbxtool (debug

> tool) immediately following in the stack. It eventually crashes

> downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string

> is trying to be accessed as pData = str.pData;

>

>

>

> Stack Trace:

>

>

>

> (dbx) where

>

> current thread: t@1

>

> =>[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in 
> "ustring.hxx"

>

>       [2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = 
> CLASS, rsContext = CLASS), line 51 in "Context.cxx"

>

>       [3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 
> 0xebc6d6b0, rEvent = STRUCT), line 257 in "SideBarController.cxx"

>

>       [4] 
> com::sun::star::uno::Reference<sfx2::sidebar::SidebarController>::Reference(this
>  = 0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in "Reference.hxx"

>

>       [5] sfx2::sidebar::SidebarController::SidebarController(this = 
> 0xebc6d6b0, pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in 
> "SidebarController.cxx"

>

>

>

> I can provide more of the stack trace if needed. Thanks in Advance!

>

> Raymond





---------------------------------------------------------------------

To unsubscribe, e-mail: 
api-unsubscr...@openoffice.apache.org<mailto:api-unsubscr...@openoffice.apache.org>

For additional commands, e-mail: 
api-h...@openoffice.apache.org<mailto:api-h...@openoffice.apache.org>


---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org

Reply via email to