PfRingDevice::startCaptureSingleThread maybe crash after exits the funtion

[prudens]

Bug description

Describe the bug
in PfRingDevice.cpp file, has a functio named PfRingDevice::startCaptureMultiThread.

When this function executes to cond.notify_all() and then exits the function. However, since variables like cond are passed to the thread above in the form of pointers to be called in another thread, if this function finishes executing before the thread, cond may become an invalid pointer.

Code example to reproduce

bool PfRingDevice::startCaptureMultiThread(OnPfRingPacketsArriveCallback onPacketsArrive, void* onPacketsArriveUserCookie, CoreMask coreMask)
{
...
	        std::mutex mutex;
	        std::condition_variable cond;
...
		m_CoreConfiguration[coreId].Channel = m_PfRingDescriptors[rxChannel++];
		m_CoreConfiguration[coreId].RxThread = std::thread(&pcpp::PfRingDevice::captureThreadMain, this, &cond, &mutex, &startThread);
...
	startThread = 2;
	cond.notify_all();
}
void PfRingDevice::captureThreadMain(std::condition_variable* startCond, std::mutex* startMutex, const int* startState)
{
	while (*startState == 0)
	{
		std::unique_lock<std::mutex> lock(*startMutex);
		startCond->wait_for(lock, std::chrono::milliseconds(100));
	}
	if (*startState == 1)
	{
		return;
	}
        ...
}

Expected behavior
Perhaps the logic should be changed to pass in shared_ptr objects, promise objects, or implement other safe control logic?

PcapPlusPlus versions tested on

v23.09

Other PcapPlusPlus version (if applicable)

No response

Operating systems tested on

Linux

Other operation systems (if applicable)

No response

Compiler version

clang 18

Packet capture backend (if applicable)

No response

[Dimi1010]

Wow... that mutex and cv should very much not be on the function stack...