QLocalServer bug
Posted: Tue Apr 23 2024 9:58 pm
All,
When my application is built with the 1.8.1 packages that can be found here
https://sourceforge.net/projects/csscintilla/files/
and were created April of last year right after a fresh merge of the current CopperSpice, all is perfect. When a second instance is started it checks the lock file and then sends any files from the command line to the running instance.
The server dutifully listens, emits the newConnection() signal and handleNewConnection() is successfully called.
With the 1.8.2 packages from the January merge, no worky.
The second instance (PID on right) sends the file name and waitForBytesWritten() succeeds but the running instance never reads the socket. Documentation for newConnection() states
https://www.copperspice.com/docs/cs_overview/timeline.html
Is there a new preferred method of solving this problem? I don't want to write to a file because that is just a disaster waiting to happen.
When my application is built with the 1.8.1 packages that can be found here
https://sourceforge.net/projects/csscintilla/files/
and were created April of last year right after a fresh merge of the current CopperSpice, all is perfect. When a second instance is started it checks the lock file and then sends any files from the command line to the running instance.
Code: Select all
void RDSingleton::startServer()
{
if ( m_server )
{
// in case this somehow gets called twice
return;
}
QLocalServer::removeServer( SERVER_NAME ); // in case there was some kind of crash
m_server = new QLocalServer( this );
m_server->listen( SERVER_NAME );
connect( m_server, &QLocalServer::newConnection, this, &RDSingleton::handleNewConnection );
logStream() << applicationPid() << " server started\n";
logStream().flush();
}With the 1.8.2 packages from the January merge, no worky.
Code: Select all
107818 ================= Starting ==== Tuesday, April 23, 2024 4:35:02 PM CDT
107818 starting server
107818 server started
107837 ================= Starting ==== Tuesday, April 23, 2024 4:35:24 PM CDT
107837 setting state to NOT_ONLY_ONE
107837 sending to existing instance
107837 filesOnCommandLine called with: 1
107837 skipZero: 0 arg: /usr/bin/reddiamond
107837 skipZero: 1 arg: /home/roland/code-scraps/more-scraps.cpp
107837 calling sendToExistingInstance: /home/roland/code-scraps/more-scraps.cpp
107837 sendToExistingInstance() called with: /home/roland/code-scraps/more-scraps.cpp
107837 file exists
107837 socket connected
107837 waitForBytesWritten() succeeded
107837 returned from filesOnCommandLine() call
107837 ================= Ended ==== Tuesday, April 23, 2024 4:35:24 PM CDT
According to the timeline found here:This signal is emitted every time a new connection is available.
https://www.copperspice.com/docs/cs_overview/timeline.html
Was this bug introduced by that fix?Correct memory leak in network sockets
Is there a new preferred method of solving this problem? I don't want to write to a file because that is just a disaster waiting to happen.