On 8 May 2017 at 10:32, Colin Ian King <1672...@bugs.launchpad.net> wrote:
> exec'ing from a thread is an interesting problem; the semantics of exec > should be to terminal all the threads before the exec occurs according > to http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_44.html > > The normal idiom would be to do: > fork() > child exec's > parent waits for child > > I'm not sure in your case if you desire all the threads to terminate > after the exec, so the wait() may be in fact be replaced by pthread > termination calls on all the threads for your implementation. > The original bug report was about a process calling execve directly, not a fork/exec situation. So yes, the expectation is that all threads are gone. > Unfortunately there is an issue with fork'ing in a thread; any mutex > held by another thread at the moment of fork becomes locked forever > since we have once mutex locked by the parent and one by the child. > Normally one would therefore use pthread_atfork() to help workaround > this issue, see https://stackoverflow.com/questions/14407544/mixing- > threads-fork-and-mutexes-what-should-i-watch-out-for Go doesn't support forking (except for some very careful code that calls exec in the child), for exactly this sort of reason. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F.... pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware 1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp