uNetworking / uWebSockets

Simple, secure & standards compliant web server for the most demanding of applications
Apache License 2.0
17.29k stars 1.75k forks source link

Crash in write call of response of POST/DELETE but works with GET #1664

Closed varma08420 closed 1 year ago

varma08420 commented 1 year ago

Hi, I have been using uWebSockets for long time on RHEL Linux 7XX but currently moved to RHEL 8XX, i have compiled code on 8XX platform started the http server, but my process getting crashes while sending response through write method. i am using /uWebSockets-0.16.0b1/src/App.h. this case was not seen when i used RHEL 7XX compiled library.

thanks!

varma08420 commented 1 year ago

sorry , i have not provided sufficient info. i have implemented simple Http server

uWS::SSLApp* mp_app = new uWS::SSLApp(); char l_li_vip[RT_MAX_IP_LEN]; strncpy(l_li_vip,m_li_vip,RT_MAX_IP_LEN);

   mp_app->listen(m_li_port,&f1); 
   mp_app->post("/LI_REQUEST",&rtProcessHttpPOSTRequest);
   mp_app->del("/LI_REQUEST",&rtProcessHttpPOSTRequest);
   mp_app->get("/*",&rtProcessHttpGETRequest);
   mp_app->run();

void rtProcessHttpPOSTRequest(uWS::HttpResponse res, uWS::HttpRequest req) { } void rtProcessHttpGETRequest(uWS::HttpResponse res, uWS::HttpRequest req) { } in rtProcessHttpPOSTRequest function i am distributing request to another pthread through which response is sent by using res->write() and res->end(). write function is causing crash like below

0 0x00000000004744db in uWS::AsyncSocket::write (this=0x7fb6e4097e70, src=0x54ea7c "HTTP/1.1 ", length=9, optionally=false, nextLength=0)

at third_party/uWS/include/AsyncSocket.h:144

1 0x00000000004740ea in uWS::HttpResponse::writeStatus (this=0x7fb6e4097e70, status=...)

at third_party/uWS/include/HttpResponse.h:187

2 0x0000000000473726 in uWS::HttpResponse::write (this=0x7fb6e4097e70, data=...)

at third_party/uWS/include/HttpResponse.h:226

3 0x000000000046cfed in RtLIX1Handler::rtSendErrorRespToLim (this=0x1cce090, a_li_resp_data=..., ap_resp=0x7fb6e4097e70)

at RtLIX1Handler.cpp:2044

but GET works without any problem in which i am sending data to client in response with sequence number. processing time between request and response is less than 1 sec. any suggestions to avoid crashing ?? am i doing anything wrong by using different threads ?? should i use single thread??

varma08420 commented 1 year ago

@uNetworkingAB anything??

uNetworkingAB commented 1 year ago

Pro tip: when you write C++, always use AddressSanitizer and ThreadSanitizer. These tools would show you the UB very clear. The lib is single threaded, you can't just jump threads like that

varma08420 commented 1 year ago

@uNetworkingAB thanks for your tip, i have used lib asan and got the following output..

==108692==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110001800e4 at pc 0x0000004ced53 bp 0x7f0b96dd9d70 sp 0x7f0b96dd9d60 READ of size 4 at 0x6110001800e4 thread T42

0 0x4ced52 in uWS::HttpResponse::writeStatus(std::basic_string_view<char, std::char_traits >) third_party/uWS/include/HttpResponse.h:180

1 0x4cd0a2 in uWS::HttpResponse::write(std::basic_string_view<char, std::char_traits >) third_party/uWS/include/HttpResponse.h:226

2 0x4c2416 in RtLIX1Handler::rtSendRespToLim(RtLIX1RespData, uWS::HttpResponse, RtDBOpData, std::vector<RtLITargetData, std::allocator >) RtLIX1Handler/src/RtLIX1Handler.cpp:2465

3 0x4cb9eb in RtLIX1Handler::rtHandleFileDumpResponse(RtLIX1RespData*) RtLIX1Handler/src/RtLIX1Handler.cpp:3550

4 0x4b477d in RtLIX1Handler::rtHandleTransactionRequest(RtHttpRequestData*) RtLIX1Handler/src/RtLIX1Handler.cpp:1288

5 0x4aaa65 in RtLIX1Handler::rtRun() RtLIX1Handler/src/RtLIX1Handler.cpp:297

6 0x4a0f8b in RtBaseThread::rtStartFunc(void*) RtBaseThread/include/RtBaseThread.hpp:610

7 0x7f0bdc4fb149 in start_thread (/lib64/libpthread.so.0+0x8149)

8 0x7f0bda027dc2 in __clone (/lib64/libc.so.6+0xfcdc2)

0x6110001800e4 is located 228 bytes inside of 240-byte region [0x611000180000,0x6110001800f0) freed by thread T46 here:

0 0x7f0be12ff7e0 in __interceptor_free (/lib64/libasan.so.5+0xef7e0)

1 0x585c4a in us_loop_run src/eventing/epoll.c:88

previously allocated by thread T46 here:

0 0x7f0be12ffba8 in __interceptor_malloc (/lib64/libasan.so.5+0xefba8)

1 0x585796 in us_loop_run src/eventing/epoll.c:61

2 0x3a14101400020523 ()

Thread T42 created by T0 here:

0 0x7f0be1262ea3 in __interceptor_pthread_create (/lib64/libasan.so.5+0x52ea3)

1 0x49f100 in RtBaseThread::rtThreadStart() RtBaseThread/include/RtBaseThread.hpp:273

2 0x493ab6 in RtLIX1Mgr::rtInitialize(char*, unsigned int) RtLIX1Mgr/src/RtLIX1Mgr.cpp:275

3 0x4783c5 in RtLIProcMgr::rtStartAppIntf(RtProcCurrentState&) RtLIProcMgr/src/RtLIProcMgr.cpp:577

4 0x5294be in RtBaseCompMgr::rtStartProc(char*, unsigned int) /include/common//RtBaseCompMgr/include/RtBaseCompMgr.hpp:1155

5 0x5274ce in main main.cpp:847

6 0x7f0bd9f4e492 in __libc_start_main (/lib64/libc.so.6+0x23492)

Thread T46 created by T0 here:

0 0x7f0be1262ea3 in __interceptor_pthread_create (/lib64/libasan.so.5+0x52ea3)

1 0x49f100 in RtBaseThread::rtThreadStart() RtBaseThread/include/RtBaseThread.hpp:273

2 0x4d7756 in RtLIHttpHandler::rtInitialize(unsigned int, char*, unsigned int) RtLIHttpHandler/src/RtLIHttpHandler.cpp:158

3 0x494183 in RtLIX1Mgr::rtInitialize(char*, unsigned int) RtLIX1Mgr/src/RtLIX1Mgr.cpp:330

4 0x4783c5 in RtLIProcMgr::rtStartAppIntf(RtProcCurrentState&) RtLIProcMgr/src/RtLIProcMgr.cpp:577

5 0x5294be in RtBaseCompMgr::rtStartProc(char*, unsigned int) /include/common//RtBaseCompMgr/include/RtBaseCompMgr.hpp:1155

6 0x5274ce in main main.cpp:847

7 0x7f0bd9f4e492 in __libc_start_main (/lib64/libc.so.6+0x23492)

SUMMARY: AddressSanitizer: heap-use-after-free third_party/uWS/include/HttpResponse.h:180 in uWS::HttpResponse::writeStatus(std::basic_string_view<char, std::char_traits >) Shadow bytes around the buggy address: 0x0c2280027fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280027fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280027fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280027ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280028000: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c2280028010: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fa fa 0x0c2280028020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280028030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280028040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280028050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2280028060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==108692==ABORTING