Posted: Sat Jul 19, 2003 1:22 pm Post subject: OO.o crashes on startup
I'm trying to install OO.o 1.0.3 on a dual 1GHz mac. It seems to be crashing when it starts up. I have not seen any reference to the particular error messahe that I am getting.
After I see the OO spalash screen, I get a dialog box from Start OO that says: could not launch openOffice.org.
The details dialog box contains the message:
dyld: /Users/jstotz/Library/Preferences/OpenOffice.org1.0.3/program/soffice.bin relocation overflow (local relocation in /Users/jstotz/Library/Preferences/OpenOffice.org1.0.3/program/libj641mxp_g.dylib relocation entry 0 does not fit in 2 bytes)
The /tmp/StartOO file is empty. I thought it should at least contain the above message.
Thread 0 Crashed:
#0 0x8fe01280 in halt
#1 0x8fe17a80 in local_relocation
#2 0x8fe03de8 in map_library_image
#3 0x8fe031d0 in load_library_image
#4 0x8fe06134 in load_images_libraries
#5 0x8fe05b28 in load_dependent_libraries
#6 0x8fe147c0 in _dyld_NSAddImage
#7 0x9001577c in NSAddImage
#8 0x002a0098 in osl_psz_loadModule
#9 0x0029fff4 in osl_loadModule
#10 0x0063c994 in cppu::loadSharedLibComponentFactory(rtl::OUString const &, rtl::OUString const &, rtl::OUString const &, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const &, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> const &)
#11 0x00272028 in stoc_loader::DllComponentLoader::activate(rtl::OUString const &, rtl::OUString const &, rtl::OUString const &, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> const &)
#12 0x006266fc in cppu::ORegistryFactoryHelper::createModuleFactory(void)
#13 0x00625dcc in cppu::ORegistryFactoryHelper::createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#14 0x00713208 in stoc_smgr::OServiceManager::createInstanceWithArgumentsAndContext(rtl::OUString const &, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#15 0x00713664 in stoc_smgr::OServiceManager::createInstanceWithArguments(rtl::OUString const &, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &)
#16 0x00007cf8 in Desktop::Main(void)
#17 0x00d36f78 in SVMain(void)
#18 0x00eb8960 in main
#19 0x000026b0 in _start
#20 0x000024e0 in start
Thread 1:
#0 0x90042688 in semaphore_timedwait_signal_trap
#1 0x9003e8b4 in _pthread_cond_wait
#2 0x0029ae0c in osl_waitCondition
#3 0x00c75e6c in store::OStorePageDaemon_Impl::run(void)
#4 0x00c769b8 in threadFunc
#5 0x0029f524 in osl_thread_start_Impl
#6 0x90020d48 in _pthread_body
Thread 2:
#0 0x9003142c in accept
#1 0x002aa474 in osl_acceptPipe
#2 0x001008a4 in vos::OPipe::accept(vos::OStreamPipe &)
#3 0x00017258 in desktop::OfficeIPCThread::run(void)
#4 0x000fb550 in vos::_cpp_OThread_WorkerFunction(void *)
#5 0x0029f524 in osl_thread_start_Impl
#6 0x90020d48 in _pthread_body
Posted: Sat Jul 19, 2003 8:36 pm Post subject: Re: OO.o crashes on startup
jstotz wrote:
I'm trying to install OO.o 1.0.3 on a dual 1GHz mac. It seems to be crashing when it starts up. I have not seen any reference to the particular error messahe that I am getting.
After I see the OO spalash screen, I get a dialog box from Start OO that says: could not launch openOffice.org.
The details dialog box contains the message:
dyld: /Users/jstotz/Library/Preferences/OpenOffice.org1.0.3/program/soffice.bin relocation overflow (local relocation in /Users/jstotz/Library/Preferences/OpenOffice.org1.0.3/program/libj641mxp_g.dylib relocation entry 0 does not fit in 2 bytes)
The /tmp/StartOO file is empty. I thought it should at least contain the above message.
That's not a good error to get
I believe the "/tmp/StartOO*" file is emptied at appropriate times, such as when you dismiss the Details dialog, to prevent the Details getting too large (and possibly misleading) if you repeatedly run into problems without quitting "Start OpenOffice.org".
As to your particular error - I don't think I have seen that specific error (although I have pccasionally seen similar errors while working with development versions of OOo).
I think we need more info about your hardware/software configuration, and for you to try a few things.
I would suggest at least rebooting, and trying to launch "Start OpenOffice.org" again, before doing anything else.
If that doesn't help, I would suggest configuring your machine to use only 1 CPU (although I don't think the Dual CPU is the problem). For info on how to do that, visit :
Posted: Sun Jul 20, 2003 2:40 pm Post subject: Re: OO.o crashes on startup
I downloaded a new copy of the OO.o installer, deleted the original installation, and reinstalled it. It now launches correctly. I have not tested it any more than that.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 20, 2003 11:56 pm Post subject:
Thanks for the crashlog. I think you may have hit another manefistation of the "dualie" problem. The message from dyld is interesting though...our other manifestations just result in crashes, not linker errors.
There is something wrong with threading/mutexes/something-or-other that exhibits itself only on MP machines. When running on a single, these threading problems don't exist. We've known something fishy is going on with dual processor machines, but haven't been able to track down what it is. Disabling one of the processors usually fixes the issue, but then, you no longer have a dual processor machine.
I assume from your last post that this is no longer reproducing...aside from reinstallation, can you recall what further steps you may have done between the two installs?
FWIW the only known reliable way to reproduce dualie problems and crashes is to run the X11 based installer (setup...or, the tarball). During the "Creating Local Settings" phase, it usually crashes on a dualie. In the G5 test labs, it crashed every single time I tried it, usually in OPageStore threads. So this is either a locking issue, or may be an underlying problem with threaded I/O, or what have you.
In short, during actual application running we've not seen the problem occur until now (you're the first I know of). The solution is that we create our install image on a single-processor Mac so folks with dualies never have to run the one known reproducable crash.
Sorry for the anonymous post - having trouble with my login today.
I don't know if my crash log will provide any new information, but here it is below. My machine is a dual 1GHz MDD Power Mac, 1 GB RAM, running Jaguar 10.2.8. My X-windowing system is Apple's X11.
I cannot get OOo to start at all, other than displaying the splash screen, then displaying a error message that it "Could not launch OpenOffice.org."
Thread 0 Crashed:
#0 0x0178d36c in rtl::OUString::_createFromAscii(char const *)
#1 0x0177ef94 in UcbStore::_getImplementationName_Static(void)
#2 0x0177d7b8 in component_getFactory
#3 0x0063d098 in cppu::_loadSharedLibComponentFactory(rtl::OUString const &, rtl::OUString const &, rtl::OUString const &, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const &, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> const &)
#4 0x00272028 in stoc_loader::DllComponentLoader::_activate(rtl::OUString const &, rtl::OUString const &, rtl::OUString const &, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> const &)
#5 0x006266fc in cppu::ORegistryFactoryHelper::_createModuleFactory(void)
#6 0x006258d4 in cppu::ORegistryFactoryHelper::_createInstanceEveryTime(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#7 0x00624260 in cppu::OSingleFactoryHelper::_createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#8 0x00625380 in cppu::OFactoryComponentHelper::_createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#9 0x00712eac in stoc_smgr::OServiceManager::_createInstanceWithContext(rtl::OUString const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#10 0x00713580 in stoc_smgr::OServiceManager::_createInstance(rtl::OUString const &)
#11 0x00b7ca20 in ucb::_registerAtUcb(com::sun::star::uno::Reference<com::sun::star::ucb::XContentProviderManager> const &, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const &, rtl::OUString const &, rtl::OUString const &, rtl::OUString const &, ucb::ContentProviderRegistrationInfo *)
#12 0x00b4e838 in ucb::_configureUcb(com::sun::star::uno::Reference<com::sun::star::ucb::XContentProviderManager> const &, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const &, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, _STL::vector<ucb::ContentProviderRegistrationInfo, _STL::allocator<com> > *)
#13 0x017734b4 in UniversalContentBroker::_initialize(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &)
#14 0x006243ac in cppu::OSingleFactoryHelper::_createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#15 0x006254c0 in cppu::OFactoryComponentHelper::_createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#16 0x00625ec0 in cppu::ORegistryFactoryHelper::_createInstanceWithArgumentsAndContext(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#17 0x00713208 in stoc_smgr::OServiceManager::_createInstanceWithArgumentsAndContext(rtl::OUString const &, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &)
#18 0x00713664 in stoc_smgr::OServiceManager::_createInstanceWithArguments(rtl::OUString const &, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &)
#19 0x00b48d78 in ucb::ContentBroker_Impl::_init(void)
#20 0x00b48cc8 in ucb::ContentBroker_Impl::_init(void) const
#21 0x00b4977c in ucb::ContentBroker_Impl::_getProviderManager(void) const
#22 0x00b488a0 in ucb::ContentBroker::_getContentProviderManagerInterface(void) const
#23 0x00a6fbd4 in utl::LocalFileHelper::_ConvertURLToPhysicalName(String const &, utl &)
#24 0x0001bdec in createTemporaryDirectory(void)
#25 0x0001ba90 in registerServices(com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> &)
#26 0x00007bcc in Desktop::_Main(void)
#27 0x00d36f78 in SVMain(void)
#28 0x00eb8960 in main
#29 0x000026b0 in _start
#30 0x000024e0 in start
Thread 1:
#0 0x90042588 in semaphore_timedwait_signal_trap
#1 0x9003e7b4 in _pthread_cond_wait
#2 0x0029ae0c in osl_waitCondition
#3 0x00c75e6c in store::OStorePageDaemon_Impl::_run(void)
#4 0x00c769b8 in threadFunc
#5 0x0029f524 in osl_thread_start_Impl
#6 0x90020c28 in _pthread_body
Thread 2:
#0 0x9003130c in accept
#1 0x002aa474 in osl_acceptPipe
#2 0x001008a4 in vos::OPipe::_accept(vos::OStreamPipe &)
#3 0x00017258 in desktop::OfficeIPCThread::_run(void)
#4 0x000fb550 in vos::__cpp_OThread_WorkerFunction(void *)
#5 0x0029f524 in osl_thread_start_Impl
#6 0x90020c28 in _pthread_body
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Nov 18, 2003 9:38 am Post subject:
That's a bad one too and may be indicative of the dualie problem, but I'm really unsure. I've never seen a crash quite like this one through UCB before.
Would you mind installing the CHUD tools to disable one of the processors so we can just eliminate the dual-processor possibility?
Also, if anyone out there has a dual 2GHz G5 and wants to test out the dual-processor problem, it'd be much appreciated if they could grab the OOo pre 1.1.1 X11 based installers and try to run them. The X11 installers (e.g. same ones Sun uses on other platforms) are the only known reliable test case in 1.0.3 for testing the dual processor crash. When I tried the 1.0.3 X11 installers on a test dual 2GHz G5 they crashed every time with both processors enabled.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Nov 22, 2003 5:05 pm Post subject:
Oh, you don't need to *understand* the CHUD tools, just install them After you install them, you'll have a new CPU system preference panel. When you click on it there's a nice graphical interface for turning off one of the CPUs.
You can also use that preference panel to add an icon to your menubar if you find yourself switching things like the processor cache on and off a lot
Okay, I installed version 3.0.1 of the CHUD tools. Then I performed the following steps:
1. Started OOo 1.0.3 with the Start OpenOffice.org app - OOo crashed in a similar manner to the log I posted above.
2. Quit the Start OOo app.
3. Turned off one CPU using CHUD.
4. Verified one CPU was disabled using CPU Monitor.
5. Re-started OOo - this time the application started perfectly.
6. Quit OOo.
7. Turned the disabled CPU back on.
8. Verified both CPUs enabled using CPU Monitor.
9. Re-started OOo - started perfectly.
That's weird. Disabling then re-enabling one CPU seems to have fixed the OOo crash problem I had, at least for the time being. I've not restarted the Mac since installing the CHUD tools.
I haven't chimed in for awhile, but I wanted to give you an update. I've since restarted the Mac numerous times, with no ill effects regarding OOo. It still works great.
I upgraded to Panther, and everything's still peachy. No problems whatsoever launching and running OOo.
Posted: Thu Jan 29, 2004 5:06 pm Post subject: path problem
just got a powerbook:-) xferred all my stuff from my old iBook(366;-) & tried 2 run oo, using the config/prefs from the ibook(also running 10.3.2) but it won't go:
dyld: /Applications/OpenOffice/program/javaldx can't open library: @executable_path/libsal.dylib.3 (No such file or directory, errno = 2)
dyld: /Applications/OpenOffice/program/soffice.bin can't open library: @executable_path/libsal.dylib.3 (No such file or directory, errno = 2)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jan 29, 2004 9:32 pm Post subject:
Ack, yeah, that's awful. Espeically if you built OOo from sources (and perhaps with the 1.1.1 installer...) symlinks to absolute paths will be an issue. I believe straight "tar" will be able to handle symlinks properly, as well as owner permissions if you use the "-p" option as root. If this reads like greek, feel free to ask. Moving around OOo should be fine with a
sudo sh 'tar cfp - .; cd dest_ooo_dir && tar xvfp -'
Also be sure to check your "~/.sversionrc" file to change the path there as well.
If you're encountering symlink problems...can you please check if you accidentally got a directory "/Volumes/perdition" on your resultant system? "perdition" is the name of the hard drive where I did the 1.0.3 build. In the past some people have seen perdition crop up on their own computers. Thankfully not too many people name their hard drives "perdition" (not that I'm a sadist...) but still any accidental directories cropping up in /Volumes can really screw things up.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
After you install them, you'll have a new CPU system preference panel. When you click on it there's a nice graphical interface for turning off one of the CPUs.