Bug 152054 - SDK SimpleBootstrap_cpp.cxx stuck in cppu_threadpool::JobQueue::enter() with factory/swriter
Summary: SDK SimpleBootstrap_cpp.cxx stuck in cppu_threadpool::JobQueue::enter() with ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.2.3 release
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks:
 
Reported: 2022-11-15 15:36 UTC by till busch
Modified: 2023-01-23 21:16 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description till busch 2022-11-15 15:36:55 UTC 
after modifying SimpleBootstrap_cpp.cxx (from https://api.libreoffice.org/examples/DevelopersGuide/ProfUNO/SimpleBootstrap_cpp/) to load swriter instead of scalc:

  * frame #0: 0x00007ff8081913ea libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007ff8081cba6f libsystem_pthread.dylib`_pthread_cond_wait + 1249
    frame #2: 0x00007ff808129d02 libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 18
    frame #3: 0x0000000100202d4b libuno_cppu.dylib.3`cppu_threadpool::JobQueue::enter(void const*, bool) + 299
    frame #4: 0x0000000100209d94 libuno_cppu.dylib.3`cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) + 180
    frame #5: 0x000000010020a543 libuno_cppu.dylib.3`uno_threadpool_enter + 99
    frame #6: 0x0000000101bb77b2 libbinaryurplo.dylib`binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__1::vector<binaryurp::BinaryAny, std::__1::allocator<binaryurp::BinaryAny> >&&, binaryurp::BinaryAny*, std::__1::vector<binaryurp::BinaryAny, std::__1::allocator<binaryurp::BinaryAny> >*) + 450
    frame #7: 0x0000000101bc5618 libbinaryurplo.dylib`binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const + 344
    frame #8: 0x0000000101bc510a libbinaryurplo.dylib`binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const + 42
    frame #9: 0x00000001005e3372 libgcc3_uno.dylib`cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) + 1330
    frame #10: 0x00000001005e2b21 libgcc3_uno.dylib`cpp_vtable_call + 689
    frame #11: 0x00000001005e2806 libgcc3_uno.dylib`privateSnippetExecutor + 118
    frame #12: 0x0000000100003027 simple`main + 279
    frame #13: 0x000000010001052e dyld`start + 462

in these tests the modified SimpleBootstrap_cpp.cxx was built into a minimal app on mac os 10.14.6. the app runs fine on that same machine where it opens an empty writer document as expected.

when running the same app on mac os 12.6.1 (x86_64, as above) it only works if an instance of libreoffice is running where the writer component was opened (manually) before. starting a libreoffice calc component always works as expected.
Comment 1 Dieter 2022-12-04 05:56:41 UTC 
Till, I'm not a developer, but it looks to me, you're rather searching help for a developemnt tool than reporting a bug. Perhaps it's a better way to use developer mailing list: https://wiki.documentfoundation.org/Development/Mailing_List
Comment 2 till busch 2023-01-23 13:17:59 UTC 
this seems to be fixed in libreoffice 7.5.0.2 (RC2).

marking resolved / fixed.