libgcc_s.so.1 must be installed for pthread_cancel to work

I still see this bug in Ubuntu 7.10. This is critical: it breaks pound completely.

Well, it also happens that this bug goes away when you explicitly add libgcc_s to your binary:

in src/Makefile.am of whatever package:

LDADD = -lpthread -lgcc_s ...

or

packagenamehere_LDADD = -lpthread -lgcc_s ...

After that the warning goes away and everything just works.

I noticed that a related problem is that you need to add libgcc_s to the chroot jail for pound since it is not loaded until after the initialization has completed.

Closing the gcc-3.3 task.

 - on gutsy, libc6 depends on libgcc1, so the library is present. Unsure how
   the jail was setup.
 - glibc uses handle = __libc_dlopen ("libgcc_s.so.1") to open the library,
   it doesn't use the output of gcc --print-file-name.

Is this still happening in Jaunty/Karmic?

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Ubuntu 10.04, have all the appropriate build packages, etc.

I encountered this error when compiling Siege (http://www.joedog.org/index/siege-home). I won't claim to understand it, but it does work when I apply LuisMondesi's suggestion of explicitly adding -lgcc_s wherever -lpthread is used.

The code DOES compile cleanly on other systems, so this is clearly an Ubuntu (or Debian) bug.

I'm attaching a patch for Siege 2.70 for anyone else who is trying to use Siege with ubuntu and encounters this error. It applies itself to the configure script and forces the makefiles to add -lgcc_s. Running ./configure will generate functional Makefiles.

This clearly is not the best way to do it, and I hope the maintainers of the appropriate packages (who exactly, I don't know) fix this problem correctly.

I removed the patch tag as it is not for gcc and does not fix the problem.

The patch is for anyone googling, trying to use siege with Ubuntu, and encountering this problem.

I'm running Ubuntu 10.04 with gcc 4.4.3 and I did not get the above error when compiling siege 2.70.

I'll try again with a completely clean install tonight when I can use my
test machine.

On Fri, Aug 6, 2010 at 3:42 PM, David Conner <email address hidden>wrote:

> I'm running Ubuntu 10.04 with gcc 4.4.3 and I did not get the above
> error when compiling siege 2.70.
>
> --
> libgcc_s.so.1 must be installed for pthread_cancel to work
> https://bugs.launchpad.net/bugs/40285
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “gcc-3.3” package in Ubuntu: Fix Released
> Status in “gcc-4.4” package in Ubuntu: New
> Status in “pound” package in Ubuntu: Invalid
>
> Bug description:
> the error:
>
> libgcc_s.so.1 must be installed for pthread_cancel to work
>
> is printed by applications using pthreads and calling:
>
> set the thread to check or cancel:
> thread_setcancelstate (PTHREAD_CANCEL_ENABLE, NULL);
> pthread_setcanceltype (PTHREAD_CANCEL_DEFERRED, NULL);
>
> and then in a tight loop try to lock a mutex and call test cancel like:
> while (pthread_mutex_trylock (&progress_lock) ==
> EBUSY)
> pthread_testcancel ();
>
> if the thread is exited because the parent thread sent a pthread_exit
> (NULL); for instance, you will see that error.
>
> gcc thinks that this file is in:
> $> gcc --print-file-name=libgcc_s.so.1
> /lib/../lib/libgcc_s.so.1
>
> and not /lib/libgcc_s.so.1. though the path should really point to the same
> file in the end.
>
> This error is fixed by adding /lib to /etc/ld.so.conf and running ldconfig
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/gcc-3.3/+bug/40285/+subscribe
>

Status changed to 'Confirmed' because the bug affects multiple users.

This happens for me on Precise Pangolin alpha 2 in wine-git when I run the app from
http://bugs.winehq.org/show_bug.cgi?id=29943 after doing the required "winetricks xml3".

i am using vsftpd together with pam_mysql and i see the same error in my ftp client.

anonymous login to vsftpd works, so the problem must be with libpammysql.
any idea how to fix this?

same here, vsftpd, pam_mysql, and the error:

libgcc_s.so.1 must be installed for pthread_cancel to work
some other error in syslog:

Apr 29 18:44:22 desktop kernel: [ 1134.793477] vsftpd[7406] general protection ip:7fde81ee7b07 sp:7fde7e6ea590 error:0 in libc-2.15.so[7fde81eae000+1b3000]

Same with uwsgi and 12.04 Server

I can confirm, this affects uWSGI on 12.04.

Adding gcc-4.6 to affected, since it can be reproduced on Precise.

I got also two reports of users having this problem in kadu-0.12.2-2 installed from this PPA for Precise: https://launchpad.net/~patryk-prezu/+archive/ppa. At least one of them is running i386. The other one reports that using kadu-0.12.2-1 for this PPA: https://launchpad.net/~mati75/+archive/kadu fixes the problem for him. Currently I'm waiting to receive more details from them. I tried reproducing it on my machine, but without success so far.

affects vsftpd too,

syslog:

kernel: do_general_protection: 33 callbacks suppressed
kernel: vsftpd general protection ip:7f881af02ac7 sp:7f8817cf8590 error:0 in libc-2.15.so[7f881aec9000+1b2000]

console:
ftp localhost
..
220 Welcome to vsFTPd Server
Name (localhost:ehcp): ftp
331 Please specify the password.
Password:
libgcc_s.so.1 must be installed for pthread_cancel to work
Login failed.

In the case of Kadu this was actually caused by Kadu being built with hardened flags and one header declaring a function that was never implemented or called. We deleted that declaration and it fixed the problem. You can check for any possibly missing symbols by exporting an LD_BIND_NOW=1 environment variable and the running the program. Though, I really doubt all these apps problems are about missing symbols.

Also, if linking explicitly with -lgcc_s fixes the problem for you, you can try running `LD_PRELOAD=/path/to/libgcc_s.so.1 your_app', maybe it will work.

tried both, not helped:

# export LD_BIND_NOW=1
# /etc/init.d/vsftpd restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service vsftpd restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop vsftpd ; start vsftpd. The restart(8) utility is also available.
vsftpd stop/waiting
vsftpd start/running, process 7738
#
#
#
# ftp localhost
Connected to localhost.
220 Welcome to vsFTPd Server
Name (localhost:root): adsf
331 Please specify the password.
Password:
libgcc_s.so.1 must be installed for pthread_cancel to work
Login failed.
421 Service not available, remote server has closed connection
ftp>
ftp>
ftp>
ftp> #
#
# locate libgcc_s.so.1
/lib/i386-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libgcc_s.so.1
# LD_PRELOAD=/lib/x86_64-linux-gnu/libgcc_s.so.1 /etc/init.d/vsftpd restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service vsftpd restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop vsftpd ; start vsftpd. The restart(8) utility is also available.
vsftpd stop/waiting
vsftpd start/running, process 7760
# ftp localhost
Connected to localhost.
220 Welcome to vsFTPd Server
Name (localhost:root):
331 Please specify the password.
Password:
libgcc_s.so.1 must be installed for pthread_cancel to work
Login failed.
421 Service not available, remote server has closed connection
ftp>
ftp>

Status changed to 'Confirmed' because the bug affects multiple users.

still not solved? still same at march-2013... I will almost start to write my own programs..

I'm still seeing this on 12.04 with uwsgi.

# gcc --print-file-name=libgcc_s.so.1
/lib/x86_64-linux-gnu/libgcc_s.so.1

# ls -lah /lib/x86_64-linux-gnu/libgcc_s.so.1
-rw-r--r-- 1 root root 87K abr 16 2012 /lib/x86_64-linux-gnu/libgcc_s.so.1

On the uwsgi logs:
libgcc_s.so.1 must be installed for pthread_cancel to work
DAMN ! worker 3 (pid: 1480) died, killed by signal 6 :( trying respawn ...

The LD_PRELOAD doesn't help here.

Also hit this bug with 12.04 server and uwsgi. Really annoying. Any workaround?

Started a thread in the uwsgi mailing list to see if this can be fixed upstream. http://lists.unbit.it/pipermail/uwsgi/2013-July/006179.html

I get this in some other python app (not uwsgi). Is there any workaround?

There is a workaround to install libpam-ldap, dosent work for all but it did for me. Running 12.04.

I have/had trouble with ntpd on saucy, it simly stopped working after a while with he mentioned error message. Running directly as root works fine; running with a reduced user account does not. Setting LD_PRELOAD works.

It seems that the user separation / priviledge dropping interferes with the delayed load of the SO. Since several applications seem to be affected, some of them also using special/reduced user accounts, I'm not sure if this qualifies as a build or a setup bug, or something entirely different.

I was probably wrong -- it seems this is not related to running as restricted user per se.

Using ldd shows no reference to libgcc_s in the binary, even if I build from source and explicitly add '-lgcc_s' to the linker command line. strace shows no signs of using libgcc_s unless put into the preload environment. And ntpd always comes to a grinding halt when not run as root unless the preload environment is used. Running as root does not crash just by lucky chance, I think.

I get the same results with gcc-4.7 and gcc-4.8 on a freshly installed x64/amd64 Saucy.

As a workaround, I put libgcc_s.so.1 into /etc/ld.so.preload, since this should help most applications that run into this problem. Though this only cures the symptom: It's still not clear WHY there is no reference to the SO in the binary... Could there be some toolchain trouble?

I finally tracked it down, I think. The pthread code tries to load libgcc_s on pthread_exit(), and this dos not work when the effective user was changed -- many daemons switch from root to a restricted user, and that's one way to end up in this problem. If the library is loaded globally for the process before the user is changed, everything works.

This is a problem of the 'pthread_exit()' implementation (delayed/on-demand load of libgcc_s) and/or the 'mmap()' implementation in the kernel.

https://bugs.launchpad.net/ubuntu/+source/siege/+bug/1317812

Status changed to 'Confirmed' because the bug affects multiple users.

Check https://bugzilla.redhat.com/show_bug.cgi?id=913519 this works for ubuntu as well. You have to recompile with the fix but it works.

the fix is for vsftpd

Same problem using python3 and multithreading in Ubuntu 18.04 LTS.

libgcc_s.so.1 must be installed for pthread_cancel to work.