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>

Uh oh!

Need a history built-in #1

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions