Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
22.08.7
-
None
-
10.0.20
Description
There is a case reported by a customer. 3 queries with GROUP_CONCAT on top were going to produce a relatively long strings. This causes some memory allocation related log messages and eventually causes SEGV signal in PP. Here are the log messages:
Jan 5 16:02:04 vm-uks-edf-maria-slave threadpool[1724863]: 04.186263 |0|0|0| E 22 CAL0005: ThreadPool: Caught exception during execution: boost::thread_resource_error: Resource temporarily unavailable [generic:11]
|
Jan 5 16:02:04 vm-uks-edf-maria-slave joblist[1724863]: 04.185910 |701574|0|0| C 05 CAL0000: TupleAggregateStep::doThreadedAggregate() caught std::bad_alloc %%10%%
|
Here is the crash trace itself:
Date/time: 2023-01-05 16:02:04
|
Signal: 11
|
/usr/bin/PrimProc(+0xc012a)[0x55f6d483812a]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f66c51bd420]
|
/usr/lib/x86_64-linux-gnu/libjoblist.so(_ZN7joblist8TupleBPS23processByteStreamVectorERSt6vectorIN5boost10shared_ptrIN11messageqcpp10ByteStreamEEESaIS6_EEjjRS1_INS_7_CPInfoESaISA_EEPNS_4FIFOIN8rowgroup6RGDataEEEj+0xe9)[0x7f66c6347769]
|
/usr/lib/x86_64-linux-gnu/libjoblist.so(_ZN5boost6detail8function26void_function_obj_invoker0IN7joblist19ByteStreamProcessorEvE6invokeERNS1_15function_bufferE+0x3e)[0x7f66c635543e]
|
/usr/lib/x86_64-linux-gnu/libthreadpool.so(_ZN10threadpool10ThreadPool11beginThreadEv+0x5df)[0x7f66c513c1cf]
|
/usr/bin/PrimProc(+0xc142b)[0x55f6d483942b]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8609)[0x7f66c51b1609]
|
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f66c4c9c133]
|
Internally GROUP_CONCAT(GroupConcatNoOrder::getResult()) code allocates a buffer on heap and doesn't account the RAM allocated b/c code threats the buffer as a temporary one.
