public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sambler at alumni dot nd.edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand Date: Fri, 11 Apr 2014 05:29:00 -0000 [thread overview] Message-ID: <bug-60662-4-K6wHH7mkLz@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60662-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 --- Comment #2 from Stuart Ambler <sambler at alumni dot nd.edu> --- Using gdb on my code, it appears that the immediate problem is caused by what gthr-default.h and/or gthr-posix.h do to detect whether a program is multi-threaded, which they seem to assume is ok as a precondition for using call_once. I think they do this with the code #ifdef __GLIBC__ __gthrw2(__gthrw_(__pthread_key_create), __pthread_key_create, pthread_key_create) # define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create) Just after that code is static inline int __gthread_active_p (void) { static void *const __gthread_active_ptr = __extension__ (void *) >HR_ACTIVE_PROXY; return __gthread_active_ptr != 0; } This function is called by __gthread_once, which if __gthread_active_p() returns false, does nothing other than return -1, which results in call_once throwing a system_error. __pthread_key_create is a function in libpthread, which my gcc command line links with. It's possible to display the value of __gthread_active_ptr in main, and it's 0 at a point before call_once is called and the error is thrown, unless the this_thread::sleep_for code is uncommented, in which case __gthread_active_ptr is not 0 and there is no problem. It's not necessary for the this_thread::sleep to be executed to avoid the problem. Putting that line in a function in the same source file as main also results in nonzero __gthread_active_ptr and no problem, even if the function is never called. I thought it might depend on order of loading the libraries and gave gcc the -static option to hopefully have more control over that. Giving gcc also -v libpthread is listed before libstdc++. But with static linking, __gthread_active_ptr is 0 and the problem occurs whether or not the this_thread::sleep_for is present. So I gave up on static linking. this_thread::sleep_for calls nano_sleep, which libpthread exports. I don't know much about the linux linker, but it seems that somehow the existence of this call to nano_sleep, even if not executed, causes libpthread to be loaded in a way that gives a nonzero value for __gthread_active_ptr when it is checked. Though it may work differently on different systems, it seems like the problem may revolve around an assumption that call_once won't be called except by a multi-threaded program, and a perhaps somewhat fragile way of determining whether it's a multi-threaded program. If you still think I should report it to Ubuntu, I will. Thanks.
next prev parent reply other threads:[~2014-04-11 5:29 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-03-26 1:02 [Bug libstdc++/60662] New: " sambler at alumni dot nd.edu 2014-03-26 11:33 ` [Bug libstdc++/60662] " redi at gcc dot gnu.org 2014-04-11 5:29 ` sambler at alumni dot nd.edu [this message] 2014-04-13 22:42 ` redi at gcc dot gnu.org 2014-09-19 13:17 ` redi at gcc dot gnu.org 2020-11-23 14:00 ` redi at gcc dot gnu.org 2020-11-23 15:50 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-60662-4-K6wHH7mkLz@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).