|
From: Julian S. <js...@ac...> - 2005-07-27 21:11:25
|
> Regression tests go as expected (3 failures), and StarOffice worked ok. > Although I did see this output at the end: Good. OOo 1.1.3 on LinuxThreads works, I know that much. > > ==8095== Syscall param write(buf) points to uninitialised byte(s) > ==8095== at 0x1CC26404: write (in /lib/libc-2.2.5.so) > ==8095== by 0x1C7528E3: osl_joinWithThread (in > /lusr/opt/staroffice7/program/libsal.so.3.1.0) > ==8095== by 0x1C412377: vos::OThread::join() (in > /lusr/opt/staroffice7/program/libvos3gcc3.so) > ==8095== by 0x806EABF: > desktop::OfficeIPCThread::DisableOfficeIPCThread() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x80605F5: desktop::Desktop::DeInit() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x1B9D4C34: DeInitVCL() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1B9D4692: SVMain() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1BB987E3: main (in > /lusr/opt/staroffice7/program/libvcl645li.so) Isn't that a classic buffer-contains-uninitialised-padding problem? > Notice that the prompt is buried in there before the final output. This > could be caused by the change in how termination is handled. It is indeed. Bear in mind that OOo/SO was the first known deadlock-at- exit case and so it makes sense now that the main thread exits before all of its children. J |