Shaw Drastin

This seems to be a bug of wxWidgets (or wxpy) bundled by KiCad. Reported upstream (https://gitlab.com/kicad/code/wxWidgets/-/issues/14). A minimal reproducible example: ```python3 import wx class Frame(wx.Frame): def __init__(self, title): wx.Frame.__init__(self, None,...

Just met the same problem. Reproducible with very simple projects.

FYI RA devs [replied](https://github.com/rust-lang/rust-analyzer/issues/17873#issuecomment-2367009286).

Sorry for the delayed response, this works for me.

I think the current situation on reception handling is confusing and probably wrong. `tud_network_recv_renew` seems to be called twice in a single packet reception, the first time by `tud_network_recv_renew_r` which...

OK, I understand that we may process multiple NCM "subpackets" in one callback, and that's why we need to repeatedly call `tud_network_recv_renew`. So, I propose a solution to this issue...

I think it's in the NCM driver, which cause compatibility issues with older codes that calls `tud_network_recv_renew` directly within `tud_network_recv_cb`. And this can be fixed by my function above.

No, this will not work, because when you call `recv_transfer_datagram_to_glue_logic()`, `should_process` is false, so the `if (should_process)` block won't be executed. Keep in mind that the second call to `tud_network_recv_renew`...

This will not work when there are 3 `ntb`s handled in one call to `netd_xfer_cb`. I think either a loop or a recursion is needed in case `tud_network_recv_renew` is called...

Yes, but I think `should_process` in my code is this indication.