Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poll() is causing deadlock #618

Open
duduita opened this issue May 1, 2024 · 0 comments
Open

Poll() is causing deadlock #618

duduita opened this issue May 1, 2024 · 0 comments
Assignees

Comments

@duduita
Copy link

duduita commented May 1, 2024

Describe the bug
When making serial HTTP requests using a static HTTP client, it's causing deadlocks, given a timing issue on poll(), which is used internally by the OS when making static HTTP clients.

To Reproduce
Run the following app on WiFi:

using Meadow;
using Meadow.Devices;
using System;
using System.Net.Http;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Timer = System.Timers.Timer;
using System.Diagnostics;

using System.Net;
using System.Net.Sockets;

namespace MeadowApp
{
    // Change F7FeatherV2 to F7FeatherV1 for V1.x boards
    public class MeadowApp : App<F7FeatherV2>
    {
        private static HttpClient _httpClient = new HttpClient();
        private static Stopwatch sw = new Stopwatch();

        public override async Task Run()
        {
            int count = 0;

            _httpClient.BaseAddress = new Uri("https://postman-echo.com");
            
            Device.NetworkAdapters.NetworkConnected += async (sender, args) =>
            {
                Console.WriteLine("network connected");
                while (true)
                {
                    await DoStaticHttpRequest(count++);
                }
            };

            return;
        }


        async Task DoStaticHttpRequest(int instance)
        {
            Console.WriteLine($"start {instance}");
            string payload =
                    "haCMuUxhfcoSxhfbbOx94IzaXxMJKT8S3jGudaxHmMkGOGO0JMumL7N4GQDWHC4VvmVXCyYrPp5njOzA3qpGGeWxHhSF59ohcRnr23IFslag4B5AH7okhNB3lJAcRIh280qyH9fqKA8D04OTawvG2X5M1h226uyZj6CgRnIiIfL7q51PDFkHe5oRtmXsJu0n3ZyOrBXsThqKdnuptm0JGreVcoyMi1c0wrAkQ0gUP00oE2jHM6lFpMzwbEzSK67KVxfMK2ChkhJgRKzlGoBoCKwGEydikCWbhZQZNlwVQ7hUMqBAEPJRaTe4M6mbiYVi2oUFMzQQ1I6B9JX4eIwtTDzvQiq4bH4uky1TfIvC3MsmxIqWIQ1wFVridUJb1wKj2D5rhZMJsqzaVDJZKrA9rHBSHP1xAkqXeO1CTlUiwZJLOhg0N22KDrJmoFQBOeAJGasfqpHq9zvuODM6qbZkiR7FCGCiMbH1fnRhOI0Mucy9wDU8xGqG7ayew72uTnBx3Ulw0TM9fLBlZXsi25oD0HJ7cHa7vWeJwxe4sqD69pmvYf2ThQBhHjdUWsmBATYzxoE9P7BIoPtWVm1Z7Q1P6hCOseXtrGoUOAYWIdoHGl3tWozV1IX4JoiJQg9liCF62ZBBoiSKeRSUHkiv19CLcLltvoV8fd5mPNeQiTDYJMXJtTPSTdbDUba47P3yfc6Q4bOw2xTHOvNkOAerIb42REoA0QCXC4bHPLgNqYhqrCNv81UTk3QvgIUAcR1oRg9Zula2IgazUnevw69tShW9w5LOMsbNzFcYuf1MXbtm3rt7YCR7bV23rY0y60rGpxcS42mjMixM1LWCnyjfP6Z3kDulejWGTpDLcRosBr5v4wEA0KzLnJ6hroIaxfP3hubHGQc8Hz6LSOHSX4sVbAyNs3UupSRJ47Jp0J7gKvBSLGSHDZ1nYCVje1VmzDSljAaQGKGPsGCZfP6MmAK0iEyijtaRdeeE1VOI3sljHCgo13bbkUGfSwM5yl0sOshoLrZT";

            sw.Start();

            var content = new StringContent(payload, Encoding.UTF8);
            var result = await _httpClient.PostAsync("https://postman-echo.com/post", content);

            sw.Stop();
            Console.WriteLine($"end {instance}, success:{result.IsSuccessStatusCode}, elapsed: {sw.Elapsed.ToString()}");
            sw.Reset();
            
        }
    }
}

Expected behavior
It should not cause a deadlock.

Meadow (please complete the following information as best as you can):
Model: F7Micro
Hardware version: F7CoreComputeV2
Device name: MeadowCoreCompute

Hardware Information
Processor type: STM32F777IIK6
ID: 3A-00-21-00-0D-50-4B-55-30-38-31-20
Serial number: 20523874554B
Coprocessor type: ESP32
MAC Address -
WiFi: 4C:75:25:D5:78:A0

Firmware Versions
OS: 1.11.0.2
Mono: 1.11.0.2
Coprocessor: 1.11.0.0
Protocol: 7

Additional context

  • It's only happening on WiFI, on native networks (cell and ethernet) it's working fine.
  • The problem seems to be on poll teardown/poll interrupt handler, since before deadlocking, it was the last logs I could see.
  • This seems to be a timing issue, since when I enable USE_MEADOW_DEBUG_HELPERS or just add a few syslogs on espcp_usrsock_sockif, just to find in which part of the code we are getting stuck, the deadlocks don't happen. But, when I disable the UART trace meadow uart trace disable, then I can see them. So, it sounds to me like a timing issue indeed, since the few milliseconds the logs consume might add a delay between each poll request, consequently, somehow reducing the chance of having a deadlock.
  • This workaround seems working for now, it might give us a clue about the problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants