lwIP - A Lightweight TCP/IP stack - Bugs: bug #25695, Segmentation fault in...
You are not allowed to post comments on this tracker with your current authentication level.
bug #25695: Segmentation fault in do_writemore(struct netconn *conn)
Submitter: | Koen Deforche <kdeforche> | ||
Submitted: | Tue 24 Feb 2009 04:11:38 PM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 1.3.0 |
Jump to the original submission
Sat 18 Apr 2009 05:49:07 PM UTC, comment #12: |
Simon Goldschmidt <goldsimon> |
Fri 17 Apr 2009 10:34:15 AM UTC, comment #11: OK, done the change to the unix port for sys_sem_wait() -> sys_arch_sem_wait()
|
Kieran Mansley <kieranm> |
Fri 17 Apr 2009 10:22:38 AM UTC, comment #10: Planned release -> 1.3.1
|
Simon Goldschmidt <goldsimon> |
Thu 05 Mar 2009 07:49:21 AM UTC, comment #9: OK, now I get it: I think you are talking about a different scenario. The one Koen reported does not involve API_EVENT but is a problem with loopif calling tcpip_input from tcpip_thread.
|
Simon Goldschmidt <goldsimon> |
Thu 05 Mar 2009 07:09:31 AM UTC, comment #8: Hi Simon, I'm using the FreeRTOS port, which does call timers from within sys_sem_wait. Any port that can call poll_tcp from within API_EVENT can suffer this problem, but I'm not familiar with other ports so I don't know how general the problem is. The unexplored consequences I was talking about, are what happens when the timers are not running while waiting for a semaphore, in this case socksem or selectsem. You are far more familiar with lwip than I so I have to defer to your judgement of how 'clean' the solution is. |
Simon Braun <sjb> |
Thu 05 Mar 2009 05:57:10 AM UTC, comment #7: Setting netconn->state to _NONE would mean we would have a general problem here, not a port-only problem, which 'm not convinced of. Also, I still don't think that would be a clean solution.
|
Simon Goldschmidt <goldsimon> |
Thu 05 Mar 2009 01:35:56 AM UTC, comment #6: Hi guys, I just diagnosed exactly the same problem here at InnerRange, and came up with the same solution (setting netconn->state to NETCONN_NONE before the call to API_EVENT). I have tested this solution overnight and the problem has not recurred (was occuring within 1 hour). I think this is the correct fix because when write_msg is set to NULL, the netconn is in an intermediate, invalid state, until the 'finished' code is executed. API_EVENT must not be called while the netconn is invalid, so the simple solution is to set the state to NETCONN_NONE early. I can see how using sys_arch_sem_wait fixes the problem but it will have other unexplored consequences. |
Simon Braun <sjb> |
Tue 03 Mar 2009 03:32:38 PM UTC, comment #5: Hey all. I understand this change and it makes sense at least from the point of view that we saw this problem on the UNIX platform, but not on Win32. The problem is unfortunately not easily reproducible, but at least with this the sys_arch_sem_wait() change we have not seen it occur again. |
Koen Deforche <kdeforche> |
Tue 03 Mar 2009 01:47:09 PM UTC, comment #4: Yes, looks sensible to me. Perhaps Koen Deforche could try this out, and if it works we can commit the change to CVS. |
Kieran Mansley <kieranm> |
Sun 01 Mar 2009 05:52:38 PM UTC, comment #3: Kieran, since you seemed to be something like the unix port maintainer, do you agree with changing the sys_sem_wait calls to sys_arch_sem_wait? |
Simon Goldschmidt <goldsimon> |
Sun 01 Mar 2009 10:55:43 AM UTC, comment #2: I don't think the fix is correct: resetting the connection state should not be done in that way.
|
Simon Goldschmidt <goldsimon> |
Tue 24 Feb 2009 08:23:10 PM UTC, comment #1: Rhe fix you propose seems to be good at the first sight.
|
Frédéric Bernon <fbernon> |
Tue 24 Feb 2009 04:11:38 PM UTC, original submission:
Hey all,
|
Koen Deforche <kdeforche> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-04-18 | goldsimon | Status | In Progress | Fixed | |
Open/Closed | Open | Closed | |||
2009-04-17 | goldsimon | Status | None | In Progress | |
Assigned to | None | goldsimon | |||
Planned Release | 1.3.1 |
Powered by Savane 3.13-aa77.
Corresponding source code
Simon, having a deeper look on the code and your explanation, I have to admit you're right and the only clean solution is setting state to NONE like Koen initially suggested. I was previously looking at the wrong line in the code because of different versions.
This is fixed now.