occasional :-) coredump

[oliSeven]

Thank you very much for this great library. Thank you very much for answering my previous question so fast!

Hopefully you have another hint for me ...

i recently got a coredump in our server (threaded c++ based on ms c++ restsdk). am sorry ... but i am not able to provide any values here ... as the binary was stripped (sorry). so i am not sure which of the two oauth2_log in oauth2_cache_get went wrong. (probably the second .. as it is dependent on the cache .. this is why i asked about thread-safety ... )

the server was running fine before this for 5 days .

any help is appreciated....

#0  0x00002b12c3ee5641 in vfprintf () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x2b12c5625700 (LWP 22208))]
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.22-114.8.3.x86_64
(gdb) where
#0  0x00002b12c3ee5641 in vfprintf () from /lib64/libc.so.6
#1  0x00002b12c3f0e3d3 in vasprintf () from /lib64/libc.so.6
#2  0x00002b12c245c4c4 in oauth2_log () from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#3  0x00002b12c244c63d in oauth2_cache_get ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#4  0x00002b12c245b55d in oauth2_jose_resolve_from_uri ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#5  0x00002b12c245b63a in ?? () from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#6  0x00002b12c2459d48 in oauth2_jose_jwt_verify ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#7  0x00002b12c245db0a in oauth2_token_verify ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#8  0x00002b12bfdf62e8 in TokenValidator::validate_token_with_jwks_uri(oauth2_log_t*, std::string const&, std::string const&) () from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsrest.so.214.0
#9  0x00002b12bfdf7616 in TokenValidator::validate_token(std::string const&) ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsrest.so.214.0
#10 0x00002b12bfdaa442 in dora::rest::RESTServer::dispatch(web::http::http_request) ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsrest.so.214.0
#11 0x00002b12bfdb3d28 in std::_Function_handler<void (web::http::http_request), std::_Bind<void (dora::rest::RESTServer::*(dora::rest::RESTServer*, std::_Placeholder<1>))(web::http::http_request)> >::_M_invoke(std::_Any_data const&, web::http::http_request&&) () from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsrest.so.214.0
#12 0x00002b12c03edec7 in web::http::experimental::listener::details::http_listener_impl::handle_request(web::http::http_request) () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#13 0x00002b12c04e60b1 in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#14 0x00002b12c04ec4a0 in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#15 0x00002b12c04ed2cf in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#16 0x00002b12c04ed619 in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#17 0x00002b12c04ee5da in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#18 0x00002b12c04360df in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
   from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#19 0x00002b12c043e2af in boost::asio::detail::scheduler::run(boost::system::error_code&) ()
   from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#20 0x00002b12c04b15e9 in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#21 0x00002b12c042a51f in boost_asio_detail_posix_thread_function ()
   from /appl/local/carmen/carmena4/lib/A214INT/libcpprest.so.2.10
#22 0x00002b12c267f6da in start_thread () from /lib64/libpthread.so.0
#23 0x00002b12c3f882cd in clone () from /lib64/libc.so.6

[zandbelt]

ouch, I'm afraid I cannot do much without the symbols

[zandbelt]

a bit of a long shot, but perhaps the "key" value was NULL? in that case https://github.com/zmartzone/liboauth2/commit/af876270c1b30c7f8667bec8f943b95454c71923 should fix it

[oliSeven]

Thank you very much !! will try it. in the meantime i tried to "walk around" this potential problem by assembling the log message only if ther is a sink which want's to output ... (so more optimization than fixing ;-)

   if ((log == NULL) || (log->sinks.first == NULL) || (fmt == NULL))
        goto end;

   // =========================================================
   // guelden: ONLY generate output
   // IF there is a SINK ... which will take it
   // background:
   // ... it seems we have a nasty log-message which forces a
   // coredump in vasprintf. this way we are able to get around it
   // by reducing the log-level (???)

   int found_a_sink_that_will_log = 0;
   for (ptr = log->sinks.first; ptr != NULL; ptr = ptr->next) {
      if (level > ptr->sink->level)
         continue;
      found_a_sink_that_will_log = 1;
   }
   if (!found_a_sink_that_will_log){
      goto end;
   }

   // =============================================================

    va_start(ap, fmt);
    rc = vasprintf(&msg, fmt, ap)

[oliSeven]

Dear Mr. Zandbelt,

Just to inform you…

I got another coredump (see below). My investigation shows that in the source of “oauth2_url_decode” uses these static variables

static CURL *_s_curl = NULL; static oauth2_uint_t _curl_refcount = 0;

I assume that my problem may arise from thread parallelism which leads to a double free in my example … (My logfiles harden this theory: two request verify tokens almost simutaneusly (~11microseconds distance)) Now I simply protected the whole token verification with a mutex.

Hopefully no complications any more (I am optimistic).

Thank you again for having a look at those nasty stacktrace from the stripped binary ;-)

Oliver

(gdb) where
#0  0x00007fae05dc0247 in raise () from /lib64/libc.so.6
#1  0x00007fae05dc161a in abort () from /lib64/libc.so.6
#2  0x00007fae05dff4a4 in __libc_message () from /lib64/libc.so.6
#3  0x00007fae05e04916 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007fae05e0575b in _int_free () from /lib64/libc.so.6
#5  0x00007fae069e4d13 in ?? () from /appl/local/carmen/carmena4/lib/A214INT/libcurl.so.4
#6  0x00007fae069f1d3a in curl_easy_cleanup () from /appl/local/carmen/carmena4/lib/A214INT/libcurl.so.4
#7  0x00007fae07975831 in oauth2_url_decode ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#8  0x00007fae07976206 in _oauth2_nv_list_parse ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#9  0x00007fae079764a6 in oauth2_parse_form_encoded_params ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#10 0x00007fae07963285 in oauth2_cfg_token_verify_add_options ()
   from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsoauth.so.214.0
#11 0x00007fae0a058143 in TokenValidator::validate_token_with_jwks_uri(oauth2_log_t*, std::string const&, std::string const&) () from /appl/local/carmen/carmena4/lib/A214DOR/libdor_appsrest.so.214.0

Von: Hans Zandbelt @.> Gesendet: Dienstag, 12. Oktober 2021 18:27 An: zmartzone/liboauth2 @.> Cc: Gülden, Oliver @.>; Author @.> Betreff: Re: [zmartzone/liboauth2] occasional :-) coredump (#30)

a bit of a long shot, but perhaps the "key" value was NULL? in that case thishttps://github.com/zmartzone/liboauth2/commit/af876270c1b30c7f8667bec8f943b95454c71923 should fix it

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/zmartzone/liboauth2/issues/30#issuecomment-941172678, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWAXOWGUQCFBGUZTMF7QVYDUGROWBANCNFSM5F2QOUBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[zandbelt]

ok, I see, that is a multi-threading issue indeed; until I get around to protect that with a mutex internal to the library, the library is not multi-thread-safe indeed; thanks for reporting

[zandbelt]

that was actually addressed in liboauth 1.4.4.1