Stack corruption detected when using version 1.21 #2841
Comments
Is it an error on the host or on the device (sometimes, when
Note that now you can omit the named parameters (which will use their default values), and only keep the ones you want to change. |
|
Hi again, First of all, thanks a lot for your fast answer. The problem was located on the host. It was a bit hard in my environment to use gdb, as it is not working well on MacOS it seems. I don't really know ASAN, but it appears that I finally found the problem on my side with your second sentence. I had to remove the parameter : It seems that the parameter name was correct based on the Server switch cases, but it was breaking everything on my side :
I don't really know what can be the cause of this problem, as -1 appears to be the default value in Options.java, but removing it saved my problem. I don't know if you want to close this issue, or if you want to investigate on this problem. |
|
-1 should be handled correctly on the server side, something is probably wrong in the caller side (your client code).
Is it expected that your string contain |
|
Or maybe something related to a maximum string length in your client? If you remove other parts but keep |
Yes, I was trying to simplify the code to help reading it for the issue by removing the variables, I just forgot one
It seems it was this problem. By removing other parameters it is launching without problem. I guess I just have to cut the string on my side :) Thanks a lot for the explanation about the parameters. This is way easier now that it is named and that some of them are not required, I don't had to check everything in the code so it is a great addition :) I'm closing the issue as it is now resolved. |
|
Could you check in |
|
Ok, I was maybe a bit fast, as it seems the string was not the problem Please find attached the result of my adb logcat com.genymobile.scrcpy.Server:V I'm not experienced enough with adb, but I found my stack corruption error in the log, so it seems it might be useful for you. I reopen the issue as it may be a real problem |
This has probably happen when
Looks like a crash in stagefright (so a bug in the device). But I can't see how passing |
|
So, here is what I saw :
This is crashing, but as soon as I comment lock_video_orientation : This is working... Now, let's say I add the parameter encoder_name : This is crashing again with the same error... And for example, if I comment some other parameter, such as the log level and the bit_rate : It is now working. So, looking at this, I suppose the number of parameters we are sending to the device can make it crash for a reason I don't know. I don't see a link between the parameters I'm removing (why would removing the bit_rate or the log_level would change anything for the encoder_name ?), so I don't see any other way that it's the number of parameters which is causing the problem (or the size of the string, as you said before) |
Not related, but the version should be passed as a separate parameter (it probably works because in the end What is the final string length if you concatenate all the arguments split by a space? Maybe there is some 255 limit or something. |
|
Also, could you reproduce with another device? It seems I can't reproduce, even if I put all arguments explicitly. |
Only counting the argument, this would be already 245 characters when using all parameters (as we saw yesterday, some of them such as lock_video_orientation can be removed as I'm using here the default value, so the problem is not impacting me anymore, it's already a good thing for me).
If I'm counting the whole command sent with adb shell, we are reaching 358 characters
I may be able to do that next week. I don't have another phone right now to try. |
|
Might be a limitation of $ printf '/ com.genymobile.scrcpy.Server 1.21 log_level=info bit_rate=8000000 max_fps=0 lock_video_orientation=-1 tunnel_forward=true send_frame_meta=false control=false show_touches=false stay_awake=false power_off_on_close=false clipboard_autosync=false encoder_name=c2.android.avc.encoder' | wc -c
281without $ printf '/ com.genymobile.scrcpy.Server 1.21 log_level=info bit_rate=8000000 max_fps=0 tunnel_forward=true send_frame_meta=false control=false show_touches=false stay_awake=false power_off_on_close=false clipboard_autosync=false encoder_name=c2.android.avc.encoder' | wc -c
255 |
|
Also got this issue on Samsung Galaxy S9 (Android 10), the same crash stack trace. Searched through Android source code and Google, looks like the In my test it only happens to And the character limit of 255 starts from doesn't crash. crashes. |
|
Hello, It seems that this problem is happening on all the devices I tested :
It's fine for me as I'm using a lot of default value, so I'm not that impacted. I still have to test based on yume-chan comment if some encoders are better than other. It may indeed be a good test, as I'm trying to use the same encoder for all my devices, which is "OMX.google.h264.encoder" (it seems to be the only encoder I have on all my phone, so I'm using this one to have the same behaviour on all devices about the encoder) |
Is the stack trace same? The |
|
Consider simplifying parameter names? |
|
I have also encountered this problem on a samsung device. After I shorten the app_process options, the error of |
|
Well I did some tests on Samsung devices with Android version of 10 and 11, it turned out that on version 10, using encoders other than |
|
Well, I use ghidra to decompile the libstagefright.so library where the suspicious reconfigEncoder4OtherApps is defined, here is the decompiled code: I don't have much ARM instruction set experience, so I try my best to check the function it called. The one thing I am sure about is the condition Then I spotted a suspicious function called I think the Then I repatched the code inside libstagefright.so, changed the code of Also, there is another function where the getProcessNameByPid is called for printing log, which is trivial to me, so I repatched the code to this: Then I used this modified ELF by pushing it to the |
|
This is just an experimental thought, and I also don't recommend repatch so file in mobile phone as well. :) |
|
I want to have some codec options enabled by default in my client, so I tried to pass options in stdin. The question is whether it's worth making such a fundamental change for only one brand. It doesn't require much code modification though. The format is like I think it's also possible to send other things in stdin. |
Environment
Describe the bug
I was using for some time scrcpy 1.17 in order to retrieve frames from the device, and decided today to update to the last version. In the previous version, I was able in Python3, following a code a bit like this one https://github.com/DawningW/swy-bot/blob/main/scrcpy.py to:
After that, I was able to receive all my frames from the video socket, and it was working perfectly fine.
In 1.21, I saw that the method to launch the server changed. In 1.17, I was using :
But in 1.21, there are now named parameters, and also new one, based on what I saw in the Server.java src code. I modified my code to something like :
After launching the server, I'm still able to get access to the dummy byte, the device name, and the screen resolution from the socket, but then I don't receive any frame anymore. I have this error happening :
stack corruption detected (-fstack-protector) AbortedMy question is, is it still possible to retrieve frames this way ? And if it is the case, is there a parameter that is not working like that anymore, and that would explain why I have a problem retrieving the frames from the video socket now ?
Thanks a lot for your time.
The text was updated successfully, but these errors were encountered: