segfault after cancelling transfer

[nicolas-s]

I'm using windows 10 and the device run latest master version of uMTP-Responder with functionfs on a 4.14.78 kernel.
Here are the steps to reproduce :

• Connect the device
• Copy from the device a file
• During the copy cancel the transfer
• Try to copy another file from the device -> segfault

In attachement you have the output of umtprd since I request the cancel (umtprd_log.txt) and the backtrace output of the coredump (umtprd_backtrace.txt).

It seems that after the cancel, the session is closed and on the new session we never pass through the MTP_OPERATION_OPEN_SESSION operation to create the 'fs_db' of the session.

[jfdelnero]

It seems that after the cancel, the session is closed and on the new session we never pass through the MTP_OPERATION_OPEN_SESSION operation to create the 'fs_db' of the session.

Yes this appears to be the cause of the segfault : The pc didn't see that the connection was closed on the device side and the uMTP should check the session status before responding to commands. But this is not the root cause of the issue. The read error is the problem.
What is your device CPU ? and which Windows 10 version have you ?

[jfdelnero]

BTW are you using the latest tagged version or the one present on the trunk ?

[nicolas-s]

I run the uMTP responder on a imx6ul CPU with a 4.14.78 kernel and my Windows 10 pro version is 10.0.18362.

I'm using this commit 39a2999 from the master because with the 1.0.0 release I have read error due to the buffer size.

I also have an RNDIS function configured on the same interface. I'll try to put only the MTP to see if it has an impact.

[jfdelnero]

i have added the session status check in the operation functions. The mtp responder shouldn't segfault anymore if the usb link is flakey (read error...). Now i will try to add some workaround to keep the connection up even if we have some read error...