Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

occasional :-) coredump #30

Closed
oliSeven opened this issue Oct 12, 2021 · 6 comments
Closed

occasional :-) coredump #30

oliSeven opened this issue Oct 12, 2021 · 6 comments

Comments

@oliSeven
Copy link

oliSeven commented Oct 12, 2021 •
edited by zandbelt
Loading

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
Copy link
Member

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

@zandbelt
Copy link
Member

zandbelt commented Oct 12, 2021 •
edited
Loading

a bit of a long shot, but perhaps the "key" value was NULL? in that case af87627 should fix it

@oliSeven
Copy link
Author

oliSeven commented Oct 12, 2021 •
edited by zandbelt
Loading

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
Copy link
Author

oliSeven commented Oct 13, 2021 via email •
edited by zandbelt
Loading

@zandbelt
Copy link
Member

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
Copy link
Member

zandbelt commented Mar 3, 2022

that was actually addressed in liboauth 1.4.4.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zandbelt @oliSeven