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

Should use posix_spawn instead of fork #11

Closed
ridiculousfish opened this issue May 21, 2012 · 1 comment
Closed

Should use posix_spawn instead of fork #11

ridiculousfish opened this issue May 21, 2012 · 1 comment
Milestone
fish 2.0.0

Comments

@ridiculousfish
Copy link
Member

Let's migrate to posix_spawn.

  • It will force us to get rid of all of the dangerous "post-fork" code.
  • It will be faster on OS X and possibly BSDs.
@niemeyer niemeyer mentioned this issue Jun 5, 2012
Closed
@ridiculousfish
Copy link
Member Author

Fixed with commit 61686af

@DarkStarSword DarkStarSword mentioned this issue Sep 10, 2012
Closed
DarkStarSword added a commit to DarkStarSword/fish-shell that referenced this issue Sep 10, 2012
@DarkStarSword
Remove wperror causing pthreads weirdness
843a62d 
I'm not entirely sure what is going on, but on one machine I run fish on
a couple of times a day I find an instance of fish using 100% CPU.
Killing it never kills an interactive session, so it is presumably
something fish is doing in the background.

strace shows it repeatedly calling sys_FUTEX with an invalid op (0xef).
Since the op is invalid, the kernel returns -ENOSYS, but pthreads keeps
spinning hoping for success and uses 100% CPU.

The backtraces always look similar to:

> (gdb) bt
> #0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> fish-shell#1  0x00007f9739351861 in pthread_rwlock_rdlock ()
>     at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_rdlock.S:120
> fish-shell#2  0x00007f973884e778 in __dcigettext (domainname=<optimized out>, msgid1=0xef <Address 0xef out of bounds>,
>     msgid2=0x0, plural=-1, n=0, category=<optimized out>) at dcigettext.c:460
> fish-shell#3  0x00007f97388a0ad8 in *__GI___strerror_r (errnum=5, buf=0x0, buflen=0) at _strerror.c:65
> fish-shell#4  0x00007f97388a09de in strerror (errnum=951726048) at strerror.c:33
> fish-shell#5  0x000000000050f15e in wperror(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) ()
> fish-shell#6  0x00000000004cfd0b in do_builtin_io(char const*, char const*) ()
> fish-shell#7  0x00000000004d1038 in exec(parser_t&, job_t*) ()
> fish-shell#8  0x00000000004f1ed8 in parser_t::eval_job(tokenizer*) ()
> fish-shell#9  0x00000000004f2629 in parser_t::eval(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, io_
> fish-shell#10 0x00000000004cfb9c in internal_exec_helper(parser_t&, wchar_t const*, block_type_t, io_chain_t&) ()
> fish-shell#11 0x00000000004d07bc in exec(parser_t&, job_t*) ()
> fish-shell#12 0x00000000004f1ed8 in parser_t::eval_job(tokenizer*) ()
> fish-shell#13 0x00000000004f2629 in parser_t::eval(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, io_
> fish-shell#14 0x000000000051fac0 in event_fire_internal(event_t const*) ()
> fish-shell#15 0x00000000005200c7 in event_fire(event_t*) ()
> fish-shell#16 0x00000000004f8a5e in proc_fire_event(wchar_t const*, int, int, int) ()
> fish-shell#17 0x000000000053ee7b in main ()

There is some weirdness here - in particular, the errnum passed to
strerror randomises (but is never sensible), the msgid1 is passed as
0xef (i.e. the same as the op passed to sys_FUTEX).

Until I better understand what is going on, remove the wperror call that
is present in every backtrace. I'll keep an eye on things and see if it
happens again.

Signed-off-by: Ian Munsie <darkstarsword@gmail.com>
@JanKanis JanKanis mentioned this issue Dec 14, 2012
Closed
@ridiculousfish ridiculousfish mentioned this issue Jun 2, 2013
Closed
@Atalanttore Atalanttore mentioned this issue Sep 25, 2014
Closed
@ridiculousfish ridiculousfish mentioned this issue Oct 27, 2015
Closed
@faho faho mentioned this issue Feb 9, 2017
Closed
2 tasks
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
fish 2.0.0
Development

No branches or pull requests
1 participant
@ridiculousfish