Hi John, On Wednesday 17 October 2007 04:05, John Wolfe wrote:
> These use Java and the hotspot error file presents the following > stack trace: > > C 0x00000004 > C [libuno_cppu.so.3+0x78537] uno_any_construct+0x118f > C [libuslc_uno.so+0xca88] cpp_vtable_call+0x32c > C [libuslc_uno.so+0x145d1] privateSnippetExecutorClass_cctor+0x11 > C [libuno_cppuhelperuslc.so.3+0x640b4] > iquery__Q5_3com3sun4star3uno13BaseReferenceSFPQ5_3com3sun4star3uno10XInterf >aceRCQ5_3com3sun4star3uno4Type+0x30 C [libuno_cppuhelperuslc.so.3+0x8f97e] > disposeAndClear__Q2_4cppu25OInterfaceContainerHelperFRCQ5_3com3sun4star4lan >g11EventObject+0x242 C [libtk680ci.so+0x31783c] > dispose__16UnoButtonControlFv+0xa8 > C [libtk680ci.so+0x2f48cc] dispose__19UnoControlContainerFv+0x35c > C [libtk680ci.so+0x35f972] dispose__16UnoDialogControlFv+0xb6 > C [libuslc_uno.so+0x1009e] > callVirtualMethod__23__Nuno2cpp_cxx_f42b3feaFPvlT118_typelib_TypeClassPlT2+ >0xba C [libuslc_uno.so+0xfd13] > cpp_call__23__Nuno2cpp_cxx_f42b3feaFPQ4_7bridges7cpp_uno6shared17UnoInterfa >ceProxyQ4_7bridges7cpp_uno6shared10VtableSlotP33_typelib_TypeDescriptionRefe >rencelP24_typelib_MethodParameterPvPPvPP8_uno_Any+0x40f C > [libuslc_uno.so+0xf389] > dispatch__Q4_7bridges7cpp_uno6shared17UnoInterfaceProxySFP14_uno_InterfaceP >C24_typelib_TypeDescriptionPvPPvPP8_uno_Any+0x305 C > [libjava_uno.so+0x3501f] > call_uno__Q2_7jni_uno6BridgeCFRCQ2_7jni_uno11JNI_contextP14_uno_InterfaceP2 >4_typelib_TypeDescriptionP33_typelib_TypeDescriptionReferencelPC24_typelib_M >ethodParameterP13_jobjectArray+0x3b3 C [libjava_uno.so+0x3259a] > Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call+0x141e > J > com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(JLjava/lang/String;Lja >va/lang/String;[Ljava/lang/Object;)Ljava/lang/Object; J > com.sun.star.bridges.jni_uno.JNI_proxy.invoke(Ljava/lang/Object;Ljava/lang/ >reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; v > ~RuntimeStub::alignment_frame_return Runtime1 stub > j $Proxy13.dispose()V+9 > j com.sun.star.wizards.letter.LetterWizardDialogImpl.closeDocument()V+4 > j com.sun.star.wizards.letter.LetterWizardDialogImpl.finishWizard()V+306 > j com.sun.star.wizards.ui.WizardDialog.finishWizard_1()V+1 > v ~StubRoutines::call_stub > > The symptom is either a missing, uninitialized or incorrect virtual > function table. From my point of view, that means a problem in the bridge. Are you sure that your code that constructs the trampolines for virtual methods is really correct? Can you debug it to see what _exactly_ went wrong in uno_any_construct/cpp_vtable_call/privateSnippetExecutorClass_cctor? > What I would like to do is fix this issue and get the 2.0.3 version > in the hands of some other users to stress the new bridge code, > as I integrate my changes into the 2.2.x tree. I'd recommend you to extract the patches you've done, and try to apply it against more recent sources, ideally 2.3. Not that it should fix your problem, but will definitely ease you the integration up-stream. > How can I determine what source files where changed in > the qwizardsbf1 and qwizardspp4 bundles that were checked into the > source tree? In ooo-build (http://www.go-oo.org), we have a script for that, cws-extract (http://svn.gnome.org/viewvc/ooo-build/trunk/bin/cws-extract). Ideally checkout ooo-build, and run it in your tree using 'cws-extract qwizardsbf1', and you'll get the patch showing changes in qwizardsbf1. Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
