[MCOL-857] PrimProc thread leak on ByteStream advance Created: 2017-08-03  Updated: 2017-08-17  Resolved: 2017-08-17

Status: Closed
Project: MariaDB ColumnStore
Component/s: PrimProc
Affects Version/s: 1.0.10
Fix Version/s: 1.0.11, 1.1.0

Type: Bug Priority: Blocker
Reporter: Andrew Hutchings (Inactive) Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 1
Labels: None

Sprint: 2017-15, 2017-16

 Description   

On BPP destroy and abort we call advance on ByteStream. It is possible that we don't have enough data in the buffer yet which causes an exception to be thrown. This exception is uncaught causing the BPPHandler thread to be leaked and the following error on PrimProc's stderr:

ByteStream: advanced beyond the end of the buffer



 Comments   
Comment by Andrew Hutchings (Inactive) [ 2017-08-03 ]

Pull request for 1.0 and 1.1

For testing run test001 and run this afterwards:

sudo cat /proc/`pidof PrimProc`/status | grep Threads

You should end with roughly 118 threads. In my tests before the patch this always leaks between 30 and 300 threads. (so 148 - 418 threads shown)

If you enable PrimProc log files (mcsadmin setProcessConfig PrimProc pm LogFile on) you'll see in /var/log/mariadb/columnstore/PrimProc.err the following message appear in the log file before the patch:

ByteStream: advanced beyond the end of the buffer

Every time this happens a thread is leaked.

After the patch this will not appear in the log file.

Comment by Daniel Lee (Inactive) [ 2017-08-17 ]

Builds verified: 1.0.11-1, 1.1.0-1

Reproduced the issue in 1.0.10-1:
[root@localhost alltest]# cat /proc/`pidof PrimProc`/status | grep Threads
Threads: 85
run test001
[root@localhost queries]# cat /proc/`pidof PrimProc`/status | grep Threads
Threads: 902

ByteStream: advanced beyond the end of the buffer
ByteStream: advanced beyond the end of the buffer
ByteStream: advanced beyond the end of the buffer
[root@localhost columnstore]# cat PrimProc.err|wc -l
816

No errors log and no threads leaked in both builds tested.

Generated at Thu Feb 08 02:24:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.