QThread::currentThreadId()

I hope that I am not making any mistake, please find the code for your reference

1. //Created in the constructor of the SerialPortManager Class

   // do the control serial port reading in a thread
   Worker* readCtrl = new Worker(this);
   readCtrl->moveToThread(&readThreadControl);
   connect(&readThreadControl, &QThread::finished, readCtrl, &QObject::deleteLater);
   connect(this, SIGNAL(startCtrlRead()), readCtrl,SLOT(readFromControlPort()));
   readThreadControl.start();

   // do the control serial port writing in a thread
   Worker* writeCtrl = new Worker(this);
   writeCtrl->moveToThread(&writeThreadControl);
   connect(&writeThreadControl, &QThread::finished, writeCtrl, &QObject::deleteLater);
   connect(this, SIGNAL(startCtrlWrite()), writeCtrl,SLOT(writeToControlPort()));
   writeThreadControl.start();

So here are two threads created on for read and write

How read works

1.Main Thread has a connect call that listens to any data coming to the serial port
connect(controlPort, SIGNAL(readyRead()), this, SLOT(readDataFromCtrl()));

2. void SerialPortManager::readDataFromCtrl()
{ emit startCtrlRead();}

Here at this point read worker thread is called.

3. void Worker::readFromControlPort()
{
if( mSerialManager->controlPort != NULL)
{
QByteArray data = mSerialManager->controlPort->readAll();
Datamanager::getInstance()->addToInQueueCtrl(data);
}
}
4.void Datamanager::addToInQueueCtrl(QByteArray msgData)
{
mInQueueCtrl.append(msgData);
emit inQueueCtrlHasItem();
}
So from here we can read the data from the queue

How Write works

1. The data is framed and added to the write queue.
   Datamanager::getInstance()->addToOutQueueCtrl(msgData);

2. addToOutQueueCtrl() emits the signal which is handled by the write worker thread and SLOT writeToControlPort() is called .

3. void Datamanager::addToOutQueueCtrl(QByteArray msgData)
   {
   mOutQueueCtrl.append(msgData);
   emit outQueueCtrlHasItem();
   }

4. connect(Datamanager::getInstance(),SIGNAL(outQueueCtrlHasItem()),
   serialPortManager,SLOT(writeDataToCtrl()));

5. void SerialPortManager::writeDataToCtrl()
   {
   emit startCtrlWrite();
   }

6. Here is what write worker thread executes the SLOT and write the data to port

7. void Worker::writeToControlPort()
   {
   if( mSerialManager->controlPort != NULL)
   {
   while( !Datamanager::getInstance()->isOutQueueCtrlEmpty())
   {
   QByteArray data = Datamanager::getInstance()->getItemFromOutQueueCtrl();
   int size = mSerialManager->controlPort->write(data);
   if( size > 0)
   {
   qDebug() << "Control Serial Port Write Succesful: " << size ;
   }
   else
   {
   qDebug() << "Control Serial Port Write Error: " << size ;
   }
   }
   }
   else
   {
   qDebug() << "NO Serial Port Connection to Write ";
   }
   }

I can understand that it can be common thread problem, but it was working fine for a long time .
I will check for the thread ID as well to make sure on that part.

Just read about the right way using the threads. You should to create the QSP instance and to call its methods only from the same thread.

E.g. if your worker was created in context of thread #2, then Worker::writeToControlPort() should be called too from the context of thread #2. Check the right thread id, just use QThread::currentThreadId() in ctor of Worker and inside of Worker::writeToControlPort() to see that this ID same.

PS: Read documentation, it is a main advice to you, before asking on a forum!!! It is simple...

And from the looks of it, Datamanager::getInstance()->getItemFromOutQueueCtrl(); may very well become invalid during the write process. As it seams to be a singleton and may be accessed by different threads?
One shouldn't do that, but it won't result in a compiler error.

Please rather check @Christian-Ehrlicher's suggestion:

And where do you check for mSerialManager != nullptr? Or is it guaranteed that it can never be nullptr? And is controlPort really correctly initialized and not a dangling pointer?

That seems much more a possible cause for your problem.

Regards

Function: QIODevice::write(QByteArray const&)
0x4a3bc1 <+0x0025> mov %ebx,0x4(%esp)
0x4a3bc5 <+0x0029> mov %esi,0x8(%esp)
0x4a3bc9 <+0x002d> mov %eax,(%esp)
0x4a3bcc <+0x0030> mov %edx,%ecx
0x4a3bce <+0x0032> mov 0x544914,%eax
0x4a3bd3 <+0x0037> call *%eax
0x4a3bd5 <+0x0039> sub $0xc,%esp
0x4a3bd8 <+0x003c> lea -0x8(%ebp),%esp
0x4a3bdb <+0x003f> pop %ebx
0x4a3bdc <+0x0040> pop %esi
0x4a3bdd <+0x0041> pop %ebp
0x4a3bde <+0x0042> ret $0x4
Function: _ZN9QIODevice5writeERK10QByteArray
0x4a3be1 <+0x0045> nop
0x4a3be2 <+0x0046> nop
0x4a3be3 <+0x0047> nop

Please find the attched screenshot for the same

if( mSerialManager->controlPort != NULL)

And where do you check for mSerialManager != nullptr? Or is it guaranteed that it can never be nullptr? And is controlPort really correctly initialized and not a dangling pointer?

if( mSerialManager->controlPort != NULL)
{
    QByteArray data = Datamanager::getInstance()->getItemFromOutQueueCtrl();
    int size = mSerialManager->controlPort->write(data);
    mSerialManager->controlPort->waitForBytesWritten(-1);
}

or you could turn the QByteArray into a static one:

if( mSerialManager->controlPort != NULL)
{
    static QByteArray data = Datamanager::getInstance()->getItemFromOutQueueCtrl();
    int size = mSerialManager->controlPort->write(data);
}

int size = mSerialManager->controlPort->write(data);

Does it crash at this line?

You need to check that mSerialManager and controlPort are valid pointers.

but on crash it goes to that line what I mentioned

mostly looks like the QByteArray issue

Then try return write(data); instead. No need to pass QByteArray internals