Bug #5050
closed
java exception in multithreaded application
Added by ofer benoliel over 3 years ago. Updated almost 2 years ago.
0%
Description
running multiple XSL transforms in multiple threads cause an exception and crash
Files
| jet_err_7380.txt (32.5 KB) jet_err_7380.txt | ofer benoliel, 2021-07-29 09:51 | ||
| SaxonClient.cpp (4.92 KB) SaxonClient.cpp | ofer benoliel, 2021-07-29 12:09 |
Related issues
Updated by Michael Kay over 3 years ago
Thanks for reporting this. Is this a one-off, or is it reproducible? Can you supply a repro so we can investigate the failure "in the lab"? Without that, I'm afraid it's unlikely we will be able to make progress.
We do need to check that you are using the APIs correctly, for example not using classes that are not thread-safe in multiple threads. Showing us the way you invoke the transformations would be helpful.
As you are probably aware, diagnosing problems like this is made more difficult by the fact that the technology platform, Excelsior Jet, no longer has a support team in place.
Updated by ofer benoliel over 3 years ago
- File SaxonClient.cpp SaxonClient.cpp added
Thanks for answering.
This issue is reproducible both in Windows and Linux. It happens only when Saxon/C is called from multiple threads.
We cannot send a repo as the system is very large and consist of many components. I attached the library wrapper we use to access Saxson/C.
How are we going to deal with future technical issues if Excelsior Jet is deprecated and has no support?
Regards
Ofer
From: Saxonica Developer Community notifications@plan.io
Sent: Thursday, July 29, 2021 11:50 AM
Subject: [Saxon/C - Bug #5050] java exception in multithreaded application
Updated by Martin Honnen over 3 years ago
Are you trying to use the same Xslt30Processor instance from different threads?
Updated by O'Neil Delpratt over 3 years ago
Hi Ofer, Thanks again for reporting this issue. In the current release the Xslt30Processor object does not support multi-threading as it not state-less. If an Xslt30Processor object fails in one of the threads then the whole program will fail. I am working on multi-threading support for the next release.
I suggest as a work around you could use the copy constructor of Xslt30Processor for each thread. Alternatively I see in your code in the Init function you create the Xslt30Processor with @gProcessor->newXslt30Processor();@. This should work where you start each thread.
If you can run your program with gdb debugger it will stop Excelsior Jet intercepting the exception therefore get a better idea of what is causing the crash.
Updated by Michael Kay over 3 years ago
(Having said that, if you are indeed running the same Xslt30Processor in more than one thread, then we don't really need to know exactly where it fails - it's going to fail somewhere because it's not designed to be multi-threaded.)
Updated by ofer benoliel over 3 years ago
Hi,
As can be seen in the code I attached, every time we interface with saxon we pass a context pointer that holds the pointer to Xslt30Processor.
This context is unique per thread. The Xslt30Processor is allocated by a global (non-thread specific) SaxonProcessor object.
Does the call to SaxonProcessor ->newXslt30Processor(); is not thread safe? Should it be protected?
Ben
From: Saxonica Developer Community notifications@plan.io
Sent: Friday, July 30, 2021 2:49 PM
Subject: [Saxon/C - Bug #5050] java exception in multithreaded application
Updated by O'Neil Delpratt over 3 years ago
- Status changed from New to AwaitingInfo
Is it possible you can create small code repo that I can run your program with threads on my linux box please?
It might be useful for you to run your program with the debugger gdb which may show up some more information as to the cause of the crash
Updated by O'Neil Delpratt over 3 years ago
- Category set to C++ API
- Assignee set to O'Neil Delpratt
- Found in version set to 1.2.1
Updated by ofer benoliel over 3 years ago
Of course we have utility programs we can operate to check these scenarios. But they cannot be ripped off from the same reason I told you.
It seems the exception is coming from one of the many threads created by Saxon:
The one marked in red is the source of the exception with the following stack:
libsaxonpec.dll!0000000000f9048e() Unknown
000000000000097c() Unknown
0000000000000065() Unknown
0000020900000000() Unknown
000000000000097c() Unknown
0000008462dfed30() Unknown
0000000000000030() Unknown
Not Flagged 55484 0 Worker Thread ntdll.dll thread ntdll.dll!00007ff8f152e7e4
Not Flagged 29588 0 Main Thread Main Thread PocoFoundation64d.dll!Poco::NamedEventImpl::waitImpl
Not Flagged 27452 0 Worker Thread LaaSServices.dll!GeneralBaseThread::ThreadProc win32u.dll!00007ff8ef151104
Not Flagged 15984 0 Worker Thread winmm.dll thread winmm.dll!00007ff8de342751
Not Flagged 62496 0 Worker Thread netbios.dll thread netbios.dll!00007ff8de651c17
Not Flagged 21584 0 Worker Thread PocoFoundation64d.dll!Poco::ThreadImpl::runnableEntry‑() PocoFoundation64d.dll!Poco::EventImpl::waitImpl
Not Flagged 66596 0 Worker Thread PocoFoundation64d.dll!Poco::ThreadImpl::runnableEntry‑() PocoFoundation64d.dll!Poco::EventImpl::waitImpl
Not Flagged 62688 0 Worker Thread PocoFoundation64d.dll!Poco::ThreadImpl::runnableEntry‑() mswsock.dll!00007ff8ee0f80fc
Not Flagged 65976 0 Worker Thread PocoFoundation64d.dll!Poco::ThreadImpl::runnableEntry‑() PocoFoundation64d.dll!Poco::EventImpl::waitImpl
Not Flagged 56740 0 Worker Thread ntdll.dll thread ntdll.dll!00007ff8f152e7e4
Not Flagged 48920 0 Worker Thread ntdll.dll thread ntdll.dll!00007ff8f152e7e4
Not Flagged 59076 0 Worker Thread ntdll.dll thread ntdll.dll!00007ff8f152e7e4
Not Flagged 69048 0 Worker Thread ntdll.dll thread ntdll.dll!00007ff8f152e7e4
Not Flagged 53024 0 Worker Thread perfos.dll thread perfos.dll!00007ff8de89518d
Not Flagged 18800 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 33268 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 59776 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 53212 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 65096 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 51152 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 46820 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 66464 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 68940 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 51740 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 42880 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 16736 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 7484 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 48308 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 35872 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 28132 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 39968 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged 59332 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!00000000004042f8
Not Flagged > 27952 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!0000000000f9048e
Not Flagged 46616 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!000000000040e183
Not Flagged 39156 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!000000000040e183
Not Flagged 35992 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!000000000040e183
Not Flagged 68924 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!000000000040e183
Not Flagged 60776 0 Worker Thread libsaxonpec.dll thread libsaxonpec.dll!000000000040e183
From: Saxonica Developer Community notifications@plan.io
Sent: Sunday, August 1, 2021 8:28 PM
Subject: [Saxon/C - Bug #5050] (AwaitingInfo) java exception in multithreaded application
Updated by O'Neil Delpratt over 2 years ago
- Status changed from AwaitingInfo to In Progress
After the recent bug fix to #5373 I am revisiting this bug issue.
Updated by O'Neil Delpratt over 2 years ago
- Related to Bug #5373: Python multithreading code crashes added
Updated by O'Neil Delpratt almost 2 years ago
- Status changed from In Progress to Closed
- Fixed in version set to 11.3
I am closing this bug issue as it seems to be related to bug issue #5373. Please reopen if problem still occurs.
Please register to edit this issue
.