seaf-server crashes during upload #1928
Comments
|
Ah, forgot to give the system details: |
|
This could be a problem specific to BSD. We haven't had similar reports on the other platforms. |
|
This got closed because it is fixed or because BSD is not supported? Would be nice to get an a brief explanation on actions. Thanks ;) |
|
Because it is bsd. I'm only a community member. |
|
This is due to a newer version of libevhtp. This behavior isn't in seafile that is bundled with the old version of libevhtp because it appeared after that point. Newer versions of libevhtp will allocate to a buffer instead of the heap (older versions always use heap). Seafile can make a request that will cause a buffer overflow in libevhtp which is probably the error you are seeing here. (would need more debugging output to be positive) A fix is to pass -DEVHTP_HAS_C99=false during the build which will force allocation to the heap instead of a buffer. A fix will be added to FreeBSD ports shortly applying the above. |
libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 MFH: 2019Q3 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@510747 35697150-7ecd-e111-bb59-0022644237b5
libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 MFH: 2019Q3 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@510747 35697150-7ecd-e111-bb59-0022644237b5
libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 MFH: 2019Q3
Fix stack overflow that can occur in libevhtp libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 Approved by: ports-secteam (joneum)
Fix stack overflow that can occur in libevhtp libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 Approved by: ports-secteam (joneum)
libevhtp allocates a stack based on data length when C99 is detected at compile time. There are no checks to verify that the stack is big enough which can cause a stack overflow. Adding EVHTP_HAS_C99=false at compile time changes this behavior by allocate to a buffer which has proper checks in place. More information about this bug can be found at: Yellow-Camper/libevhtp#118 haiwen/seafile#1928 MFH: 2019Q3
On the client I get:
It seems the seaf-server is constantly crashing:
The logs doesn't seem to contain any interesting info
controller.log
Sadly the core file doesn't have debug symbols:
I wonder what file it is on the client that causes the crash, but the client log, or the client programs don't seem to say (or I am not looking in the right places).
The text was updated successfully, but these errors were encountered: