Yes, that's true. The dhcp_discover function (which calls dhcp_create_msg) is being called from the tcp_ip main loop thread and the input processing function is on another thread which will call dhcp_select (that calls dhcp_create_msg as well). Therefore in summary, dhcp_create_msg is being called from 1) dhcp_discover (because of dhcp timers and from tcpip_thread) and 2) from dhcp_select due to an input packet with the following stack call: my_driver_input_packet_callback->ethernet_if_input->ip_input->udp_input->dhcp_recv->dhcp_handle_offer->dhcp_select->dhcp_create_msg.
So this is the problem, but I don't know how to solve it, because tcp_init function create a new thread and my input buffer are coming from another thread. Could you please tell me how to handle this situation? I tried LWIP_TCPIP_CORE_LOCKING but did not help. Thanks, On Thu, Mar 27, 2014 at 2:20 PM, Simon Goldschmidt <[email protected]> wrote: > Behrooz Shafiee wrote: > > > LWIP_ASSERT("dhcp_create_msg: dhcp->p_out == NULL", dhcp->p_out == > NULL); > > > > using some outputs I realized this happens because dhcp_create_msg being > called consecutively without a dhcp_delete_msg in between. > > [..] > > I don't know the lwip mechanics but I am guessing sometimes the > dhcp_delete_message takes longer than usual I guess... > > I have attached a log file as well. > > The way your log output is formatted suggests that you are violating > lwIP's threading requirements and more than one thread is active in the > core at the same time: trace output of ip_input is mixed with that of dhcp > functions. > I guess this sometimes results in two threads running the deco code at the > same time, which is not supported. > > Simon > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users > -- Behrooz
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
