Bug 3164

Hi Roman, could you upload one of the broken desktop file for us to try to reproduce the issue? Thanks!

Created attachment 2999 [details]
Desktop.tgz

All the three icons disappear at the error message.

Thanks Roman. 
I placed your files on my desktop and if I click on the files, here is what I get:

- Steam: dialog saying "TDEInit could not launch '/usr/share/playonlinux/playonlinux'.

- OpenScada: nothing happens. If I edit the file and remove the "env..." part from the executable, I get "TDEInit could not launch '/usr/bin/openscada'."

- picoscope: "The desktop entry file /usr/share/applications/picoscope.desktop has no Type=... entry."

I can't seem to reproduce the problem. Not sure if using master instead of R14.0.x makes a difference, nothing comes to my mind to be honest.

(In reply to Michele Calgaro from comment #3)
> I can't seem to reproduce the problem. Not sure if using master instead of
> R14.0.x makes a difference, nothing comes to my mind to be honest.

That reproduces only at the desktop start up, not at these icons start up, and not in each start, estimated as in 1 of 3 starts.

Created attachment 3001 [details]
desktop files error.png

Reproduction like that.

Ok thanks for the info. I will keep the files in the desktop folder and see if I can get the same issue sooner or later.

Some details about the bug, which means as a conceptual problem of the DCOP interface in mixing of processing different requests.

I reproduce the problem relatively staidly at the start since I have at least two concurrent senders through DCOP, that are:
1. the kdesktop process at sending "requestSlave(TQString,TQString,TQString)" for files.
2. KRFB initiated early for starting, which is requesting geometry of the same desktop.

So, the bug is appeared at receiving by kdesktop a response for KRFB as the mime type response TQRect instead of expecting TQDataStream.

Hi Roman,
thanks for the extra feedback on this. I am still not able to reproduce it, even using the files you uploaded long ago.
Can you elaborate more on your explanation about DCOP being the issue? DCOP is a point to point protocol, so I am not sure I understand what you tried to explain.

Is KRFB started automatically when TDE start? And is an active connection established before you see the bug? Just trying to see if I can find a way to reproduce it here too.

OK, let's catch that together! :)

For catch that I have changed for debug messages:
- the file dcopclient.cpp on the client side for "TEST 1*"
- the file tdelauncher.cpp on the server side for "TEST 3*"

And at the error reproducing I have in the .xsession-errors:
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 10
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 11: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 12: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 13: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"

[2021/03/30 22:14:27.105] TEST 30: status=0; iceConn=0x55d97fa30860; readyRet=1; sequence_of_request=24; major_opcode_of_request=1; minor_opcode_of_request=2; io_ok=1; connection_status=1
[2021/03/30 22:14:27.105] TEST 30a: sequence_of_request=24; transactionId=0; status=1; replyType=7; replyData=16
[2021/03/30 22:14:27.106] [kdesktop] ERROR: : couldn't create slave

>>> So, there performed the termination-intruding of some non typical essence with replyType=7; replyData=16, when correct ones for the "file" protocol are replyType=9; replyData=8

[2021/03/30 22:14:27.134] [tdeio (TDEIOConnection)] ERROR: TEST 14: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.134] [tdeio (TDEIOConnection)] ERROR: TEST 15: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"

Created attachment 3017 [details]
dcopclient.cpp

Changed for the debug messages "TEST 1*"

Created attachment 3018 [details]
tdelauncher.cpp

Changed for the debug messages "TEST 3*"

So, contrariwise
> Some "file" protocol request

>> Starting the request processing in the slave
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 10
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 11: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 12: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.083] [tdeio (TDEIOConnection)] ERROR: TEST 13: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"

> Some intruding

>> Return to client the error message
[2021/03/30 22:14:27.105] TEST 30: status=0; iceConn=0x55d97fa30860; readyRet=1; sequence_of_request=24; major_opcode_of_request=1; minor_opcode_of_request=2; io_ok=1; connection_status=1
[2021/03/30 22:14:27.105] TEST 30a: sequence_of_request=24; transactionId=0; status=1; replyType=7; replyData=16
[2021/03/30 22:14:27.106] [kdesktop] ERROR: : couldn't create slave

>> ... continuing only of the request processing in the slave
[2021/03/30 [22:14:27.134] [tdeio (TDEIOConnection)] ERROR: TEST 14: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"
[2021/03/30 22:14:27.134] [tdeio (TDEIOConnection)] ERROR: TEST 15: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopinyZj9.slave-socket"

> Only finished the original request processing

Hi Roman,
I still can't replicate the issue here, so I am limited in the debugging I can do. I am happy to support though if I can.
Have you been able to investigate why we have reply type 7 if we are expecting 9? Obviously there must be a reason and we need to chase that to understand what is wrong with this bug.

(In reply to Michele Calgaro from comment #13)
> I still can't replicate the issue here, so I am limited in the debugging I
> can do. I am happy to support though if I can.

You can direct my thinks for placing the debug marks on the digging. :)

> Have you been able to investigate why we have reply type 7 if we are
> expecting 9? Obviously there must be a reason and we need to chase that to
> understand what is wrong with this bug.

Yes, and that reason only in dcopserver which is single-threaded, then it process the responds by linking that to some connection and what is performed sometime wrong at high activity at the start, when in the QDict container placed of waiting the io-slave response for tdedesktop and come other request which response is wrong wrote to the waiting tdedesktop connection.

In any case, that digging level I have obtained before updating to 14.0.11 and have not observed the bug during about 10 days.

So, I am placing here the last reproducing before acknowledgement it in 14.0.11:
[2021/10/24 15:15:47.993] TEST 30: iceConn=0x55f09fa30860; sequence_of_request=24; io_ok=1; connection_status=1; replyType='(null)'; replyData=(null)

> tdedesktop sends the requestSlave()

[2021/10/24 15:15:48.011] [tdeio (TDEIOConnection)] ERROR: TEST 10
[2021/10/24 15:15:48.011] [tdeio (TDEIOConnection)] ERROR: TEST 11: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopARZEa4.slave-socket"
[2021/10/24 15:15:48.011] [tdeio (TDEIOConnection)] ERROR: TEST 12: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopARZEa4.slave-socket"
[2021/10/24 15:15:48.011] [tdeio (TDEIOConnection)] ERROR: TEST 13: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopARZEa4.slave-socket"

> The request is processing in tdeio and dcopserver have moved the connection to the QDict container for waiting the response.

[2021/10/24 15:15:48.016] TEST 31: status=0; iceConn=0x55f09fa30860; readyRet=0; sequence_of_request=24; major_opcode_of_request=1; minor_opcode_of_request=2; io_ok=1; connection_status=1
[2021/10/24 15:15:48.016] TEST 32: sequence_of_request=24
[2021/10/24 15:15:48.038] TEST 31: status=0; iceConn=0x55f09fa30860; readyRet=1; sequence_of_request=24; major_opcode_of_request=1; minor_opcode_of_request=2; io_ok=1; connection_status=1
[2021/10/24 15:15:48.038] TEST 31a: sequence_of_request=24; transactionId=0; status=1; replyType='TQRect'; replyData=

> But there is coming some other request which fast TQRect response dcopserver writes to the still waiting tdedesktop connection.

[2021/10/24 15:15:48.051] [tdeio (TDEIOConnection)] ERROR: TEST 14: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopARZEa4.slave-socket"
[2021/10/24 15:15:48.051] [tdeio (TDEIOConnection)] ERROR: TEST 15: protocol="file"; host=""; socketfile="/tmp/tdesocket-roman/kdesktopARZEa4.slave-socket"

> And only here tdeio is finished the tdedesktop request processing.

Created attachment 3020 [details]
Complete log of reproducing the issue

Created attachment 3021 [details]
Complete log of the normal starting process with the debug marks

Created attachment 3022 [details]
dcopclient.cpp

Created attachment 3023 [details]
dcopclient.cpp

Created attachment 3024 [details]
tdelauncher.cpp

So, resume. Now, after 14.0.11, I am not observing the issue also as #3118, where I see one suspect essence, this is the data container QDict.

And I am waiting now the issues reproduction...

Hi Roman,
thanks for the update. 

> Yes, and that reason only in dcopserver which is single-threaded, then it 
> process the responds by linking that to some connection and what is performed 
> sometime wrong at high activity at the start, when in the QDict container 
> placed of waiting the io-slave response for tdedesktop and come other request 
> which response is wrong wrote to the waiting tdedesktop connection.
If that is the reason, it would indicate some non-threadsafe or non-reentrant method are ran and data corruption occour. Not an easy one to debug for sure.
Even if you are not seeing the issue anymore, let's keep this bug open for the time being and please update when you run into the same issue again.
I tried various time to reproduce this problem, even using your files, but so far I was never able to do so.

(In reply to Michele Calgaro from comment #21)
> If that is the reason, it would indicate some non-threadsafe or
> non-reentrant method are ran and data corruption occour. Not an easy one to
> debug for sure.
No, dcopserver is singlethreaded, so there is no reentrant and threadsafe needs.

> Even if you are not seeing the issue anymore, let's keep this bug open for
> the time being and please update when you run into the same issue again.
> I tried various time to reproduce this problem, even using your files, but
> so far I was never able to do so.
I have seen the issue reproducing once already on 14.0.11 and I am going to force it reproducing by placing some delay between TEST 13 and TEST 14, if my assumption is correct.

Created attachment 3051 [details]
.xsession-errors

Now, on some notebook, I have the mass DCOP mixing of all with all in like way and with the desktop resetting several times and some time even it is crashed.

In .xsession-errors I have these:
[2023/03/05 21:40:09.526] [tdeio (TDEIOConnection)] [1047] ERROR: Header read failed, errno=104 (pid 1047 process "nit] media /tmp/tdesocket-
roman/tdelauncherG0vxGK")
[2023/03/05 21:40:09.526] [tdeio (TDEIOConnection)] [1047] ERROR: Header has invalid size (-1) (pid 1047 process "nit] media /tmp/tdesocket-r
oman/tdelauncherG0vxGK")

Created attachment 3053 [details]
kdesktop_BackGrndPntr.patch

(In reply to Roman Savochenko from comment #23)
> Created attachment 3051 [details]
> .xsession-errors
> 
> Now, on some notebook, I have the mass DCOP mixing of all with all in like
> way and with the desktop resetting several times and some time even it is
> crashed.

And that was in the common background processing of KDesktop and I think that is related also to the original bug what is not about DCOP, which processes the concurrence calls correctly, what I have tested by simulation the concurrency, appending sllep(1) in processing the calls "requestSlave(TQString,TQString,TQString)" .

And the common problem of the KDesktop background is in the VERY BAD practice of the pointers using for the image objects KPixmap, what I have rewrote. So, the pointers are lost actively at many virtual desktops with different background images and primarily in the crossfading, next the desktop can crash at switching to the second virtual desktop after accessing the images cache with such lost KPixmap pointers.

(In reply to Roman Savochenko from comment #24)
> And that was in the common background processing of KDesktop and I think
> that is related also to the original bug what is not about DCOP, which
> processes the concurrence calls correctly, what I have tested by simulation
> the concurrency, appending sllep(1) in processing the calls
> "requestSlave(TQString,TQString,TQString)".

But the original bug is still appeared in 14.1.0 on hardware with slow SSD, like to Acer Aspire 110.