segfault in python 1.31.0

What version of gRPC and what language are you using?
Python 1.31.0.
What operating system (Linux, Windows,...) and version?
Linux 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 x86_64 x86_64 GNU/Linux
What runtime / compiler are you using (e.g. python version or version of gcc)
Python 3.5.9
What did you do?
Upgraded to 1.31.0
What did you expect to see?
No segfault
What did you see instead?
We started seeing segfaults in both our celery workers and our uWSGI logs:
!!! uWSGI process 20 got Segmentation Fault !!!
*** backtrace of 20 ***
uwsgi(uwsgi_backtrace+0x2a) [0x56079b42b2ea]
uwsgi(uwsgi_segfault+0x23) [0x56079b42b6d3]
/lib/x86_64-linux-gnu/libc.so.6(+0x3efd0) [0x7fa99c451fd0]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x270245) [0x7fa987cda245]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x267473) [0x7fa987cd1473]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x268212) [0x7fa987cd2212]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x16e6a4) [0x7fa987bd86a4]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x26cc84) [0x7fa987cd6c84]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x281fcb) [0x7fa987cebfcb]
/usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so(+0x25ccc8) [0x7fa987cc6cc8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7fa99e5b36db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fa99c534a3f]
*** end of backtrace ***
Tue Aug 11 09:44:16 2020 - uWSGI worker 3 screams: UAAAAAAH my master disconnected: i will kill myself !!!

Segmentation fault (core dumped)

We tested 1.30.0 and did not observe the segfaults anymore.
When this happens with our celery workers, what seems to trigger the segfault is when the worker is restarted after having executed the maximum tasks specified by maxtaskperchild. For example celery -A the_app worker -Q a_queue --concurrency=1 --maxtasksperchild=100 -l info.
I can't currently provide cleaned up code for you to reproduce, but I believe any code making GRPC calls should trigger this after enough time.

Hopefully this will help; this is the backtrace generated by GDB when analyzing the core dump:
#0  0x00007f8dc329ad81 in grpc_core::ExecCtx::Run(grpc_core::DebugLocation const&, grpc_closure*, grpc_error*) ()
   from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#1  0x00007f8dc329e275 in grpc_core::LockfreeEvent::SetReady() () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#2  0x00007f8dc3295458 in pollable_process_events(grpc_pollset*, pollable*, bool) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#3  0x00007f8dc3296212 in pollset_work () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#4  0x00007f8dc319c6a4 in run_poller () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#5  0x00007f8dc329ac84 in grpc_core::ExecCtx::Flush() () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#6  0x00007f8dc32affcb in timer_thread(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#7  0x00007f8dc328acc8 in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
No symbol table info available.
#8  0x00007f8dd65706db in start_thread (arg=0x7f8dc25a4700) at pthread_create.c:463
        pd = 0x7f8dc25a4700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140246827812608, -4894642692633015755,<PHONE_NUMBER>10752, 0,<PHONE_NUMBER>2064,<PHONE_NUMBER>69376,<PHONE_NUMBER>575620661,<PHONE_NUMBER>523723317},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007f8dd68a9a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

CC @veblush

After re-running tests, this seems to also affect version 1.30.0, which makes me think it something else is wrong.
A coworker of mine noted the presence of this error too:
[2020-08-11 18:05:12,629: ERROR/MainProcess] Process 'Worker-4' pid:74 exited with 'signal 11 (SIGSEGV)'
I0811 18:05:13.150826638       6 fork_posix.cc:70]           Fork support is only compatible with the epoll1 and poll polling strategies

I've seen a few conversations around discussing similar issues and that seemed related to fork.
Also, here's some more stack traces
(gdb) thread apply all bt

Thread 6 (Thread 0x7fffbb7cd700 (LWP 1536)):
#0  0x0000555555b3f2c0 in PyUnicode_Type ()
#1  0x00007fffe437f6c9 in grpc_core::ExecCtx::Flush() () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#2  0x00007fffe437b22d in pollset_work(grpc_pollset*, grpc_pollset_worker**, long) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#3  0x00007fffe429384c in run_poller () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#4  0x00007fffe437f6c9 in grpc_core::ExecCtx::Flush() () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#5  0x00007fffe4393a20 in timer_thread(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#6  0x00007fffe437301b in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#7  0x00007ffff77cc6db in start_thread (arg=0x7fffbb7cd700) at pthread_create.c:463
#8  0x00007ffff7b05a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffe2eca700 (LWP 1532)):
#0  0x00007ffff77d2ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7fffe2ec9ce0, expected=0, futex_word=0x7fffe48d324c <g_cv_wait+44>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7fffe2ec9d90, mutex=0x7fffe48d3260 <_ZL4g_mu>, cond=0x7fffe48d3220 <g_cv_wait>) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7fffe48d3220 <g_cv_wait>, mutex=0x7fffe48d3260 <_ZL4g_mu>, abstime=0x7fffe2ec9d90) at pthread_cond_wait.c:667
#3  0x00007fffe4370c7a in gpr_cv_wait () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#4  0x00007fffe4393b37 in timer_thread(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#5  0x00007fffe437301b in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#6  0x00007ffff77cc6db in start_thread (arg=0x7fffe2eca700) at pthread_create.c:463
#7  0x00007ffff7b05a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffe36cb700 (LWP 1531)):
#0  0x00007ffff77d29f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555557b94630) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555557b945d0, cond=0x555557b94608) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555557b94608, mutex=0x555557b945d0) at pthread_cond_wait.c:655
#3  0x00007fffe4370c12 in gpr_cv_wait () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#4  0x00007fffe437ffcf in grpc_core::Executor::ThreadMain(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#5  0x00007fffe437301b in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#6  0x00007ffff77cc6db in start_thread (arg=0x7fffe36cb700) at pthread_create.c:463
#7  0x00007ffff7b05a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe3ecc700 (LWP 1530)):
#0  0x00007ffff77d29f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555557b6fb30) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555557b6fad0, cond=0x555557b6fb08) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555557b6fb08, mutex=0x555557b6fad0) at pthread_cond_wait.c:655
#3  0x00007fffe4370c12 in gpr_cv_wait () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#4  0x00007fffe437ffcf in grpc_core::Executor::ThreadMain(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#5  0x00007fffe437301b in grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::{lambda(void*)#1}::_FUN(void*) () from /usr/local/lib/python3.5/dist-packages/grpc/_cython/cygrpc.cpython-35m-x86_64-linux-gnu.so
#6  0x00007ffff77cc6db in start_thread (arg=0x7fffe3ecc700) at pthread_create.c:463
#7  0x00007ffff7b05a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff7fe9740 (LWP 1521)):
#0  0x00007ffff7b05d67 in epoll_wait (epfd=9, events=0x555562ece670, maxevents=1023, timeout=1809) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x0000555555633f0a in ?? ()
#2  0x00005555556c5033 in PyCFunction_Call ()
#3  0x000055555566f0d0 in PyEval_EvalFrameEx ()
#4  0x000055555566f2f3 in PyEval_EvalFrameEx ()
#5  0x000055555566f2f3 in PyEval_EvalFrameEx ()
#6  0x00005555556ca3c2 in ?? ()
#7  0x000055555567157b in ?? ()
#8  0x00005555556c50b1 in PyCFunction_Call ()
#9  0x000055555566f0d0 in PyEval_EvalFrameEx ()
#10 0x000055555572e78f in ?? ()
#11 0x000055555572e853 in PyEval_EvalCodeEx ()
#12 0x00005555556c8c85 in ?? ()
#13 0x00005555555bbe9a in PyObject_Call ()
#14 0x0000555555669938 in PyEval_EvalFrameEx ()
#15 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#16 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#17 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#18 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#19 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#20 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#21 0x000055555572e78f in ?? ()
#22 0x000055555572e853 in PyEval_EvalCodeEx ()
#23 0x00005555556c8d75 in ?? ()
#24 0x00005555555bbe9a in PyObject_Call ()
#25 0x0000555555669938 in PyEval_EvalFrameEx ()
#26 0x000055555572e78f in ?? ()
#27 0x000055555572e853 in PyEval_EvalCodeEx ()
#28 0x00005555556c8d75 in ?? ()
#29 0x00005555555bbe9a in PyObject_Call ()
#30 0x00005555555d8c2c in ?? ()
#31 0x00005555555bbe9a in PyObject_Call ()
#32 0x000055555569ba0c in ?? ()
#33 0x00005555555bbe9a in PyObject_Call ()
#34 0x0000555555669938 in PyEval_EvalFrameEx ()
#35 0x000055555572e78f in ?? ()
#36 0x000055555566d969 in PyEval_EvalFrameEx ()
#37 0x000055555572e78f in ?? ()
#38 0x000055555566d969 in PyEval_EvalFrameEx ()
#39 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#40 0x000055555572e78f in ?? ()
#41 0x000055555566d969 in PyEval_EvalFrameEx ()
#42 0x000055555572e78f in ?? ()
#43 0x000055555566d969 in PyEval_EvalFrameEx ()
#44 0x000055555572e78f in ?? ()
#45 0x000055555566d969 in PyEval_EvalFrameEx ()
#46 0x000055555566f2f3 in PyEval_EvalFrameEx ()
#47 0x000055555572e78f in ?? ()
#48 0x00005555556664cf in PyEval_EvalCode ()
#49 0x0000555555678dd0 in ?? ()
#50 0x0000555555680aa1 in PyRun_FileExFlags ()
#51 0x0000555555680c5d in PyRun_SimpleFileExFlags ()
#52 0x0000555555723424 in Py_Main ()
#53 0x00005555555b6b1d in main ()

@huguesalary The stack trace looks slightly different in your most recent comment. Which thread segfaulted in that case? Thread 6?

I somehow managed to loose the trace and can't generate another one right now, but, I believe thread 6 was the one that segfaulted in the trace I posted in https://github.com/grpc/grpc/issues/23796#issuecomment-673076915
Now, I also had instances where the segfault that occured looked exactly like thread 1.

After deploying 1.30.0 on our production systems, the number of segfaults went down to 0.
So, although I was able to create a segfault with 1.30.0 on my own machines, it does seem 1.30.0 is more stable than 1.31.0

Two things that might be relevant to this come to my mind:

New artifacts for manylinux2014 is added from 1.31. You can try manylinux2010 artifacts by running pip --platform manylinux2010.
Added TCP_USER_TIMEOUT auto-detection (https://github.com/grpc/grpc/pull/23401). This shouldn't be invasive but this never been used in Python so chances are something isn't properly done.

Another interesting thing is the folk error message. It shouldn't be shown, I guess. Richard, gRPC Python is supposed to not use epollex at all?

I have the same problem.
After upgrading python dependencies in project we started to get kubernetes pods restart with celery workers.
There were no logs, no tracebacks, no exceptions. We enabled python faulthandler https://blog.richard.do/2018/03/18/how-to-debug-segmentation-fault-in-python/ and got different tracebacks not connected with grpc in different parts of code. By excluding last updates in working branch step by step we found that it was grpc package source of segfaults. Downgrading to 1.30.0 solved this issue

Some examples
Fatal Python error: Segmentation fault                                                   ││ │ my_process Thread 0x00007fb7bfb21740 (most recent call first):                                             ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/kombu/utils/eventio.py", line 84 in poll                           ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/kombu/asynchronous/hub.py", line 308 in create_loop                     ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/worker/loops.py", line 83 in asynloop                         ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/worker/consumer/consumer.py", line 599 in start                    ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bootsteps.py", line 119 in start                           ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/worker/consumer/consumer.py", line 318 in start                    ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bootsteps.py", line 369 in start                           ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bootsteps.py", line 119 in start                           ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/worker/worker.py", line 208 in start                         ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bin/worker.py", line 259 in run                            ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bin/base.py", line 253 in __call__                          ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bin/worker.py", line 223 in run_from_argv                       ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bin/celery.py", line 415 in execute                          ││ │ my_process  File "/usr/local/lib/python3.8/site-packages/celery/bin/celery.py", line 487 in handle_argv                        ││
Another one
Fatal Python error: Segmentation fault                                                                                ││ my_process Thread 0x00007f4dbbc50740 (most recent call first):                                                                                ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/connection.py", line 422 in _recv                                                   ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/connection.py", line 456 in _recv_bytes                                             ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/connection.py", line 243 in recv_bytes                                              ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/queues.py", line 355 in get_payload                                                 ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/pool.py", line 445 in _recv                                                         ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/pool.py", line 473 in receive                                                       ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/pool.py", line 351 in workloop                                                      ││ my_process   File "/usr/local/lib/python3.8/site-packages/sentry_sdk/integrations/celery.py", line 253 in sentry_workloop                              ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/pool.py", line 292 in __call__                                                      ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/process.py", line 114 in run                                                        ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/process.py", line 327 in _bootstrap                                                 ││ my_process   File "/usr/local/lib/python3.8/site-packages/billiard/popen_fork.py", line 79 in _launch

We're using Flask application and Google PubSub emulator and Google Datastore emulator (both communicating via grpc through client libraries) to run tests. With grpcio==1.31.0 we are getting segmentation fault errors but fortunately, with 1.30.0 it works ok. Not sure what could be the issue. We're Python 3.7.5

@gnossen Is there anything we can provide to help make progress on this issue?

Hi @gnossen, just checking in again. Is there any additional information that would be useful?

This is happening to me too with grpcio-1.33.2-cp36-cp36m-manylinux2014_x86_64. I get constant segfaults. Downgrading to 1.30.0 solves the problem.

Same here. Python multiprocessing.Process died randomly, leaving segfault message in dmesg like [6558262.243117] grpc_global_tim[42632]: segfault at 7f172819d038 ip 00007f1789caff59 sp 00007f1739bb6c40 error 4 in cygrpc.cpython-36m-x86_64-linux-gnu.so[7f1789a60000+5e8000]. Downgrading to 1.30.0 solves.
install grpcio-1.33.2-cp36-cp36m-manylinux2010_x86_64.whl does not help, still getting same error.

We faced the exact same issue - multiprocessing with grpc leading to segmentation faults. We were using 1.34.0 in our case but downgrading to 1.30.0 resolved the issue. Haven't tried it with 1.32.0 and 1.33.0 yet.

Sorry for the delay. This thread got buried in my inbox. @wireman27 @exzhawk @dmjef Can one of you please point me to your code and/or describe how to reproduce this issue?

It looks like the default polling strategy changed from epoll1 in v1.30 to epollex in v1.31. Unfortunately epollex doesn't have prefork support so it doesn't work with Celery: Fork support is only compatible with the epoll1 and poll polling strategies. We were able to work around this issue by setting GRPC_POLL_STRATEGY=epoll1 on our Celery workers.

@gnossen Reproducing might be difficult because we use google-cloud-translate to translate some text and it's exactly that snippet of the translate request to Google that seems to cause the segmentation fault. (It works fine without the translation snippet).
Important to note here is that we initialise 10 sub-processes with multiprocess.Process() and each of these sub-processes are making translation requests. The output of these 10 sub-processes is then funnelled through a multiprocess.Queue() that is picked up by another multiprocess.Process(). Hope this helps.

I am able to reproduce it (or something very similar using 1.20.1. I am running uwsgi in master/worker mode and anytime a GRPC request is issued, I get the following segfault:
Thread 8 (Thread 0x7f41ff4c1700 (LWP 7018)):
#0  0x00007f4216f9836b in pthread_rwlock_wrlock () from /usr/lib64/libpthread.so.0
#1  0x00007f41fd8e3a49 in CRYPTO_THREAD_write_lock ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#2  0x00007f41fd89cf6f in OBJ_NAME_remove ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#3  0x00007f41fd890a5c in OPENSSL_LH_doall ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#4  0x00007f41fd89d167 in OBJ_NAME_cleanup ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#5  0x00007f41fd884c1e in evp_cleanup_int ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#6  0x00007f41fd88e10a in OPENSSL_cleanup ()
from /usr/local/lib64/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#7  0x00007f4214cd5ce9 in __run_exit_handlers () from /usr/lib64/libc.so.6
#8  0x00007f4214cd5d37 in exit () from /usr/lib64/libc.so.6
#9  0x000000000042258f in uwsgi_exit ()
#10 0x000000000046b3a1 in uwsgi_segfault ()
#11
#12 grpc_core::LockfreeEvent::SetReady (this=0x31e5d50) at src/core/lib/iomgr/lockfree_event.cc:210
#13 0x00007f420847626c in fd_become_writable (fd=0x31e5cb0)
at src/core/lib/iomgr/ev_epollex_linux.cc:826
#14 pollable_process_events (pollset=pollset@entry=0x23c5f70,
pollable_obj=pollable_obj@entry=0x23b10e0, drain=drain@entry=false)
at src/core/lib/iomgr/ev_epollex_linux.cc:925
#15 0x00007f420847713a in pollset_work (pollset=0x23c5f70, worker_hdl=,
deadline=) at src/core/lib/iomgr/ev_epollex_linux.cc:1147
#16 0x00007f42084e6031 in run_poller (arg=0x23c17b0, error=)
at src/core/ext/filters/client_channel/backup_poller.cc:122
#17 0x00007f420847b859 in exec_ctx_run (error=0x0, closure=)
at src/core/lib/iomgr/exec_ctx.cc:40
#18 grpc_core::ExecCtx::Flush (this=0x7f41ff4c0cf0) at src/core/lib/iomgr/exec_ctx.cc:148
#19 0x00007f420848b7ee in run_some_timers () at src/core/lib/iomgr/timer_manager.cc:140
#20 timer_main_loop () at src/core/lib/iomgr/timer_manager.cc:246
#21 timer_thread (completed_thread_ptr=0x23c7790) at src/core/lib/iomgr/timer_manager.cc:293
#22 0x00007f4208524bb3 in ?? () from /ovn/lib/libgrpc.so.7
#23 0x00007f4216f94ea5 in start_thread () from /usr/lib64/libpthread.so.0
#24 0x00007f4214d9a96d in clone () from /usr/lib64/libc.so.6

We have a similar issue.
We are running processes in multiprocessing using google cloud pubsub. The code we are using is very similar to the function synchronous_pull_with_lease_management from the pubsub client examples
With all versions above 1.30 we get messages like these:
E1215 16:57:23.081484255    5127 ssl_transport_security.cc:514] Corruption detected.
E1215 16:57:23.081556271    5127 ssl_transport_security.cc:490] error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
E1215 16:57:23.081565033    5127 ssl_transport_security.cc:490] error:1000008b:SSL routines:OPENSSL_internal:DECRYPTION_FAILED_OR_BAD_RECORD_MAC
E1215 16:57:23.081570862    5127 secure_endpoint.cc:208]     Decryption error: TSI_DATA_CORRUPTED

and then segmentation faults.
But it seems the occurrence of the segmentation fault depends on the type of process we are running.
I've not yet been able to make a minimal example. And running it with a simple time.sleep in the worker function does not show the behavior.

This is starting to be a huge issue for my team; we make heavy use of grpcio and grpc-google-iam-v1.
Downgrading to grpcio==1.30.0 did not seem to help.
Does anyone have this issue too or a workaround for working with GCP libraries?

This is starting to be a huge issue for my team; we make heavy use of grpcio and grpc-google-iam-v1.
Downgrading to grpcio==1.30.0 did not seem to help.
Does anyone have this issue too or a workaround for working with GCP libraries?

We have had this issue too and this thread was helpful for us. We have a workaround, so I thought I would provide details, in hopes it may help.
What did it was to set GRPC_POLL_STRATEGY=epoll1 on our workers that use multiprocessing with fork on linux based images.
We have been gradually getting rid of using fork in general (as it was the cause for many other issues).
This happened on workers running python 3.7.6.
We have also found that workers running on python 3.8.6 do not see this issue. However, we have seen errors like these instead:
2021-02-01 12:16:49.489 EST "Corruption detected."
2021-02-01 12:16:49.490 EST "error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT"
2021-02-01 12:16:49.490 EST "error:1000008b:SSL routines:OPENSSL_internal:DECRYPTION_FAILED_OR_BAD_RECORD_MAC"
2021-02-01 12:16:49.490 EST " Decryption error: TSI_DATA_CORRUPTED"
2021-02-01 12:16:49.490 EST "SSL_write failed with error SSL_ERROR_SSL."

which is similar to what @cpaulik  is seeing.
If I had to guess, I would naively suspect that what is occurring is that both the parent and child processes are attempting to use the same socket connection (as fork ing provides a copy) resulting in data corruption. Not sure if this helps, or if this is the wrong direction.

We have had this issue too and this thread was helpful for us. We have a workaround, so I thought I would provide details, in hopes it may help.
What we did was as suggested, to set GRPC_POLL_STRATEGY=epoll1 on our workers that use multiprocessing with fork on linux based images.
As a longterm strategy, we have been gradually getting rid of using fork in general (as it was the cause for many other issues).
This happened on workers running python 3.7.6.
We have also found that workers running on python 3.8.6 do not see this issue. However, we have seen errors like these instead:
2021-02-01 12:16:49.489 EST "Corruption detected."
2021-02-01 12:16:49.490 EST "error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT"
2021-02-01 12:16:49.490 EST "error:1000008b:SSL routines:OPENSSL_internal:DECRYPTION_FAILED_OR_BAD_RECORD_MAC"
2021-02-01 12:16:49.490 EST " Decryption error: TSI_DATA_CORRUPTED"
2021-02-01 12:16:49.490 EST "SSL_write failed with error SSL_ERROR_SSL."

which is similar to what @cpaulik is seeing.
If I had to guess, I would naively suspect that what is occurring is that both the parent and child processes are attempting to use the same socket connection (as fork ing provides a copy) resulting in data corruption. Not sure if this helps, or if this is the wrong direction.

thank you so much @jrmlhermitte I've been trying find a solution for segfault issue for a very long time. This worked like a charm.

Hi, 2022 checking in. It appears that gRPC doesn’t work with any kind of pre-fork (eg uWSGI) model system unless you specify the environment variables noted above.
Perhaps a solution would be to add some documentation?

Note: the epollex poller has been removed in gRPC 1.46.0 released in May 2022. So I don't think that the solution above to force the poller to epoll1 is still relevant today, as this is now the default.


dont panic/segv on no memory cgroup

Running promscale on a system without memory cgroups enabled results in a panic / SEGV.
~# /opt/promscale/promscale
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x6561f4]

goroutine 1 [running]:
github.com/timescale/promscale/pkg/limits/mem.getCGroupV1Memory(0x0, 0x0)
        /tmp/promscale/pkg/limits/mem/mem_linux.go:71 +0xc8
github.com/timescale/promscale/pkg/limits/mem.getCGroupMemory(0x856a01, 0x1d852c0)
        /tmp/promscale/pkg/limits/mem/mem_linux.go:43 +0x84
github.com/timescale/promscale/pkg/limits/mem.SystemMemory(0x1d85290, 0x91e4f0)
        /tmp/promscale/pkg/limits/mem/mem_linux.go:17 +0x14
github.com/timescale/promscale/pkg/limits.ParseFlags(0x1d85290, 0x1d9c7dc, 0x1d9c784)
        /tmp/promscale/pkg/limits/flags.go:109 +0x14
github.com/timescale/promscale/pkg/runner.ParseFlags(0x1d9c6e0, 0x1c9e110, 0x0, 0x0, 0xd8, 0x81c080, 0x4f701)
        /tmp/promscale/pkg/runner/flags.go:54 +0x138
main.main()
        /tmp/promscale/cmd/promscale/main.go:22 +0xa4

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hey @NixM0nk3y, thank you for this PR.
@cevian an update/fix to memory management.

bors r+

bors r+


Url length affects whitespace on edge of qr

Adding or subtracting from the url creates/removes whitespace around the actual qr code. This does not work in a normal ratio but seems very random that it sometimes jumps up and down in size.
I don't understand why this would happen, first I thought it was due to my config but it seems its the same in codepen.
https://codesandbox.io/s/l8rwl?file=/src/App.js
Try changing the url length and see that the image appears to change in size now and then.

The more characters you give to the data property the more whitespace it will add (somehow randomly). Happens in all versions tested from 1.3.xx to 1.6.xx.
Easy angular example:
https://codesandbox.io/s/l8rwl?file=/src/App.js

This problem occured when size is small. In my case, when i put a long url in a 180x180 area for qrcode, it creates whitespace around  the actual qrcode which lead to getting qrcode very small but strangely, same url on size 200x200 pixel was same as a short url qrcode.

the only thing I could figure out to correct this issue for me was changing the errorCorrectionLevel to "M"

This happens because when you add more data, the QR needs to contain more data.
To do this at some point it needs to render more "dots" (in this lib with improved styling also lines) in the QR-code to represent that data.
The more dots you have the bigger the QR becomes, however most of the time the canvas size is limited which means the "dots" need to be rendered smaller and smaller to fit within the limited canvas space e.g. 300x300.
The library renders each of the "dots" ON a pixel to prevent the QR-code from becoming blurry
So that means a dot for example is 7x7 pixels on your screen and you have 42x42 dots.
Width and height would then be: 7 x 42 = 294 pixels.
If your canvas is 300x300 you have (300-294) / 2 = 3 pixels of space around the qr-code which will be centered in the canvas.
Now you increase the amount of data and you require 43x43 dots to contain the data.
300/43 ≈ 6,98. So your dot needs 6,98x6,98 pixels or it will overflow the canvas.
The lib then switches to using 6x6 dots to prevent a blurry image.
Resulting width and height: 6 x 43 = 258 pixels.
With your 300x300 canvas you now have (300-258) / 2 = 21 pixels of space around the qr-code.
Changing the errorCorrectionLevel does not resolve this behaviour, but makes it so that for you URL range your QR-code is probably longer in the range in which the "dots" size can stay the same.

@hawkerboy7 thanks for explanation, it is totally correct!
Marking it as a duplicate of https://github.com/kozakdenys/qr-code-styling/issues/104.
You can use dotOptions.roundSize = false now.
More details in https://github.com/kozakdenys/qr-code-styling/issues/104#issuecomment-1771854501 and https://github.com/kozakdenys/qr-code-styling/issues/104#issuecomment-2425170881


npc cannot navigate out of curret spot if starting on certain blocks

If an npc starts out in tilled soil, soulsand or a slab it cannot navigate out with walk command.
It can however navigate out when starting on trapdoors, snow or carpet.
Citizens build #1474
Denizen build #1635

sorry, just realizing now that this is more likely a citizens issue, not specific to denizen


python.pkgs.pytest-watch: init at 4.2.0

Motivation for this change
Add pytest-watch.
Tested commands ptw and pytest-watch successfully with python2 and 3.7 on a small test project.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@grahamcofborg eval

Are you packaging this to use it for some other package you will submit later? In that case, it would be nice to put it all in a single PR.

Are you packaging this to use it for some other package you will submit later? In that case, it would be nice to put it all in a single PR.

No, I would just like to package pytest-watch.

This is now in nixpkgs


Unable to get IIS sites to bind to certificates in IIS CCS Central Store

I currently have several IIS servers set up to use a CCS Central Store.  All my sites are currently using a single wildcard certificate, with a single wildcard .pfx file located in the CCS.
I would like to switch to using Let's Encrypt certificates instead for each site.  I understand that Let's Encrypt doesn't really work with wildcard certs?
I set up win-acme to generate SSL certificates and place them into my IIS Central Store.  win-acme does indeed generate .pfx files for each cert in the store just like it's supposed to.
However, if I check each site in a browser, I see that they are still using the old wildcard cert, not the new certificate .pfx files.
Has anyone run into this before?

I understand that Let's Encrypt doesn't really work with wildcard certs?

You can get wildcard certificates from Let's Encrypt since 2018 and win-acme has suppored that since version 2.0.0, so you can definitely give that a shot.

However, if I check each site in a browser, I see that they are still using the old wildcard cert, not the new certificate .pfx files.

In my experience it can take some time (a few minutes) for new or updated certificates to be "seen" by the Central Store. I'm not sure what happens if you have both a wildcard and a specific domain certificate present, perhaps the wildcard is prioritized?

Ok, I'm having trouble finding it, is there documentation on how to generate a wildcard cert?
So when using a CCS I should not need to manually change any bindings myself in IIS?

Ok, I'm having trouble finding it, is there documentation on how to generate a wildcard cert?

The same way you generate other certificates, the easiest way is to let the program read it from an IIS wildcard binding, but you can also pick "manual input" and just type something like *.example.com. The catch is that you will be limited to DNS validation options though.

So when using a CCS I should not need to manually change any bindings myself in IIS?

You never have to update any bindings manually if you use this program to manage the renewal in IIS. It will even convert a regular binding to a CCS binding if you pick that as the store plugin.


I found one issue need to be fixed in transfer , "listen": "<IP_ADDRESS>:8433" ---> '<IP_ADDRESS>:8433'

in docker container, in transfer config file, rpc listen port should be '<IP_ADDRESS>:8433', is not '<IP_ADDRESS>:8433', otherwise agent in host can not connect transfer in container
"rpc": {
"enabled": true,
"listen": "<IP_ADDRESS>:8433" ---> '<IP_ADDRESS>:8433'
},

in Dockerfile, you can expose transfer and hbs port for agent in host connect


merge package from arlac77/npm-package-template

package.json

chore(package): update<EMAIL_ADDRESS>from template
chore(package): update<EMAIL_ADDRESS>from template

.travis.yml

chore(travis): remove node versions 10.3
chore(travis): add node versions 10.4

Coverage remained the same at 97.143% when pulling fcef21ccba41bd47d91bd0140644c9c201ff4888 on template-sync-1 into c2f003a77d880b6cef8a4f79915ab45c45559ed7 on master.

Codecov Report

Merging #131 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #131   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           2      2
  Lines          29     29
=====================================
  Hits           29     29

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c2f003a...fcef21c. Read the comment docs.


fix-facet-double-change-facet-action-triggered

Codecov Report

Merging #582 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #582      +/-   ##
==========================================
+ Coverage   99.74%   99.74%   +<.01%
==========================================
  Files         262      262
  Lines        6603     6604       +1
  Branches     1504     1504
==========================================
+ Hits         6586     6587       +1
  Misses         17       17

Impacted Files
Coverage Δ

src/components/facets/FacetRow.tsx
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f63b633...bb7b9dc. Read the comment docs.


When using :checked with collection_check_boxes, existing associations should be ignored

Consider a User who can have many Roles:
class User < ActiveRecord::Base
  has_many :user_roles
  has_many :roles, :through => :user_roles
end

class UserRole < ActiveRecord::Base
  belongs_to :user
  belongs_to :role
end

class Role < ActiveRecord::Base
  has_many :user_roles
  has_many :users, :through => :user_roles
end

One can make a view where a user can be edited and roles can be selected:
= simple_form_for @user do |f|
  = f.name
  = f.email
  = f.association :roles, :as => :check_boxes

By default, when requesting the edit form above, simple_form will list all possible roles that a user can have, checking the onces where a UserRole record exists for the @user object.
But if I add the :checked => [...] option to the f.association call with an array of role id's, I would expect simple_form to pre-check those roles and those roles only. What I get instead, is a set of check boxes with both the existing roles checked + the roles given in the :checked array (i.e. it has merged the @user.user_roles array with the :checked array).
I see the same issue when using f.collection_check_boxes :role_ids, Role.all, :id, :name, :checked => [...] instead of f.association ....
I would expect the array given to :checked to override any existing associations on the @user object. Otherwise simple_form will re-check un-checked check boxes on form validation errors.

Hey guys, sorry to delay that much to answer you here.
It really seems to be more a Rails issue than a SimpleForm one, we will try to check what Rails and SimpleForm are doing to see if we can find out what's going on here. Thanks.

Closed by #374


Agnostic CMS Content module

Figure out proper data format (should it be cms-specific?)
Implement component
Repalce all the occurences of other CMS content usage with new component
Make it compatible with all 3rd partys
Figure out how CMS connector should work (agnostic regarding ES so common query format)

<cms-content query="query">
// access to data, loading, error like gql components
</cms-content>

Routing for CMS pages can be done by having one route that takes the URL params and adds it as a query to the cms-content element

Hi, do you think we need to have content data in ES ?

Here are my thoughts.
Content is more than text. It is:

Structure
Design
Text
Images

This includes CSS, HTML, images and links.
A visual builder is great for content managers, saving workload on developers.
Storing a text document is not enough, such as Markdown or otherwise.
Now I know this should be an agnostic module, but I am leaning very strongly towards Wordpress myself. And I will explain why so you can get some use cases.
My plan is to use Wordpress Gutenberg visual editor as the CMS backend.
The WP rest API would output rendered HTML which is then injected into a Vue component.
The component is called either by permalink URL in Wordpress or by ID. Or maybe it could sit in graphql and be fetched using an ID matching the Wordpress ID.
The important part is using some kind of widget system, so you can choose what content goes into what position on the frontend.
A rule engine like in Magento would be very nice.  What happens when that content is obsolete and a content manager needs to delete it? A developer would have to edit the Vue template.
If you instead registered widget positions like "content.top". Then the content manager could say in the CMS "position: content.top; priority: 10" using priority to sort the content.
This approach gives us some very good bonuses:

Structure design of premade blocks is provided and managed by developers in Wordpress
A content manager can design content blocks without programming using the visual builder
The CMS is not tied to any ecommerce platform
The rendered HTML looks the same on the CMS and can be previewed, and be the same as the live store (if CSS styles are included)
The Wordpress ecosystem can provide custom blocks
Wordpress has support for custom taxonomies which are strong custom content types
The content manager decides where content goes, not the Vue developer (after initial widget placement)

I strongly believe in the output of rendered HTML from the CMS instead of building the visual design using Vue. Because if you do that, you will not have the same visual experience for the content managers as the CSS and HTML can differ making previews hard inside your CMS solution.
Now the hard problems:

Solving linking issues

Research needs to be done how the CMS links to things. Hopefully it uses relative links, but not all CMS do that.
When a user creates a link in the editor it may inject the full domain of the Wordpress installation in the rendered HTML, which requires rewrites of all URLs in the content.

Solving image issues

Where are images stored? When building content you would probably use the CMS media manager to insert image and align them where you want. When you import the rendered HTML you would need to download the images from the CMS into Vue Storefront and rewrite the URLs.

Caching

You should not call the CMS on every single page load. But if content changes it must somehow update the cache. Using a push technique from the CMS to update content is probably a good idea.

@Zyles nice research is that a feature you're working on?

@pkarw No not yet, we are still battling with Magento 2.3.3 frontend ... hopefully 2020 will be the year of headless.


Updating fontello font causes temporary (but long-lived) webpack failure

Attempting to update the fontello font files causes webpack to begin failing with:
ERROR in ./src/assets/font/fontello/font/fontello.woff?96313270
Module parse failed: /opt/projects/raster-foundry/app-frontend/src/assets/font/fontello/font/fontello.woff?96313270 Line 1: Unexpected token ILLEGAL
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
 @ ./~/css-loader?sourceMap!./src/assets/font/fontello/css/fontello.css 6:324-365

ERROR in ./src/assets/font/fontello/font/fontello.eot?96313270
Module parse failed: /opt/projects/raster-foundry/app-frontend/src/assets/font/fontello/font/fontello.eot?96313270 Line 1: Unexpected token ILLEGAL
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
 @ ./~/css-loader?sourceMap!./src/assets/font/fontello/css/fontello.css 6:83-123 6:146-186

ERROR in ./src/assets/font/fontello/font/fontello.ttf?96313270
Module parse failed: /opt/projects/raster-foundry/app-frontend/src/assets/font/fontello/font/fontello.ttf?96313270 Line 1: Unexpected token ILLEGAL
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
 @ ./~/css-loader?sourceMap!./src/assets/font/fontello/css/fontello.css 6:403-443

ERROR in ./src/assets/font/fontello/font/fontello.svg?96313270
Module parse failed: /opt/projects/raster-foundry/app-frontend/src/assets/font/fontello/font/fontello.svg?96313270 Line 1: Unexpected token <
You may need an appropriate loader to handle this file type.
| <?xml version="1.0" standalone="no"?>
| <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
| <svg xmlns="http://www.w3.org/2000/svg">
 @ ./~/css-loader?sourceMap!./src/assets/font/fontello/css/fontello.css 6:485-525

ERROR in ./src/assets/font/fontello/font/fontello.woff2?96313270
Module parse failed: /opt/projects/raster-foundry/app-frontend/src/assets/font/fontello/font/fontello.woff2?96313270 Line 1: Unexpected token ILLEGAL
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
 @ ./~/css-loader?sourceMap!./src/assets/font/fontello/css/fontello.css 6:243-285

This subsequently cascades to the ManifestRevisionPlugin which throws an exception and fails.
The error is consistent, but eventually resolves itself (usually after waiting a few hours).
https://github.com/webpack-contrib/css-loader/issues/38 seems to describe our symptoms perfectly, but as far as I can tell we're already following all of the suggestions from that thread.
This error makes it really difficult for @designmatty to add new icons because it invariably nukes his ability to do any further work for the next several hours.

The solution is the go into the fontello css file and delete the ?xxxxxxx extension on the filenames. I've been doing that every time we update the fonts.

to be clear, there's a fontello.css file
at the top it says
src: url('../font/tontello.eot?xxxxxxxx')
``` etc, with numbers instead of x's

Additionally, we need to make sure that permissions are the same between the new and old files. we've run into issues where the new files are actually different, and don't have the correct permissions.

After some further investigation with @Lknechtli , we discovered that the two errors are separate. The issues with css-loader will be fixed in an upcoming PR. However, updating the font files still causes consistent failures from ManifestRevisionPlugin for some indefinite period of time.
The error from the plugin is the following:
fs.js:982
  return binding.lstat(pathModule._makeLong(path));
                 ^

Error: ENOENT: no such file or directory, lstat 'template of 23 referencing 24'
    at Error (native)
    at Object.fs.lstatSync (fs.js:982:18)
    at ManifestRevisionPlugin.parsedAssets (/opt/projects/raster-foundry/app-frontend/node_modules/manifest-revision-webpack-plugin/index.js:72:16)
    at Compiler.<anonymous> (/opt/projects/raster-foundry/app-frontend/node_modules/manifest-revision-webpack-plugin/index.js:160:33)
    at Compiler.applyPlugins (/opt/projects/raster-foundry/app-frontend/node_modules/tapable/lib/Tapable.js:26:37)
    at Watching._done (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:78:17)
    at Watching.<anonymous> (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:61:18)
    at Compiler.emitRecords (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:282:37)
    at Watching.<anonymous> (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:58:19)
    at /opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:275:11
    at Compiler.applyPluginsAsync (/opt/projects/raster-foundry/app-frontend/node_modules/tapable/lib/Tapable.js:60:69)
    at Compiler.afterEmit (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:272:8)
    at Compiler.<anonymous> (/opt/projects/raster-foundry/app-frontend/node_modules/webpack/lib/Compiler.js:267:14)
    at /opt/projects/raster-foundry/app-frontend/node_modules/async/lib/async.js:52:16
    at Object.async.forEachOf.async.eachOf (/opt/projects/raster-foundry/app-frontend/node_modules/async/lib/async.js:236:30)
    at Object.async.forEach.async.each (/opt/projects/raster-foundry/app-frontend/node_modules/async/lib/async.js:209:22)
error Command failed with exit code 1.

The solution is the go into the fontello css file and delete the ?xxxxxxx extension on the filenames. I've been doing that every time we update the fonts. ?xxxxx i think is used for cache busting, but webpack takes care of that for us

I'm not sure if you guys have figured it out, but this doesn't actually resolve the crashing issue.

@designmatty Yup, totally -- after we fixed the stack trace in my original post it still crashes with the stack trace above.

@designmatty This has hopefully been fixed on develop; can you give it a try whenever you're in a good spot where you won't be blocked if it doesn't work?

I think this is resolved with #1734


semi public types

Deploy preview: https://kit-svelte-dev-git-semi-public-types-svelte.vercel.app/docs/types#additional-types

I tried to do this in #4021 but the merge was too gnarly. Easier to start fresh.
The basic thinking here is that we have public types in index.d.ts and ambient.d.ts, and private-but-documented types in private.d.ts. Changes to these types should be made carefully to avoid breakage.
internal.d.ts is for things that aren't referenced by public types, and can be changed freely.
So far I haven't actually moved most of the types, I've just set up the logic for extracting/rendering/linking them.

Ok I think this is ready for review. There's some further tweaks I'd like to make to the types (particularly EndpointOutput) but they probably warrant a separate PR.
The big change here, other than that private types are now documented, is that a bunch of formerly public types are now in private.d.ts. I've been quite liberal in moving things over, on the basis that we can easily move things from private.d.ts to index.d.ts, but we can't go the other way without breaking changes. The test for whether something goes in index.d.ts was 'is a user likely to need to import this type?'

@Rich-Harris, after upgrade from 1.0.0-next.285 to 1.0.0-next.286 I have an error using this code:
<script context="module" lang="ts">
	import type { LoadInput, LoadOutput } from "@sveltejs/kit";

	export function load({ url }: LoadInput): LoadOutput {
		//...
	}
</script>

Now if I copy the code from https://kit.svelte.dev/docs/loading:
<script context="module" lang="ts">
  /** @type {import('@sveltejs/kit').Load} */
  export function load({ url }) {
    //...
  }
</script>

the url is any.
Why?
Am I wrong using it?

This change made using Typescript harder. Previously, I could say
  export async function load({ fetch }: LoadInput): Promise<LoadOutput> {

Now it seems I have to use this form
  export const load: Load = ({ fetch }) => {

I know this is a style thing, and a lot of people seem to write arrow expressions everywhere, but I'm more inclined to agree with https://deno.land/manual/contributing/style_guide#top-level-functions-should-not-use-arrow-syntax

I'm not disagreeing about whether we should export LoadInput and LoadOutput, but I would think if you want to avoid arrow expressions you could write it as:
  export const load: Load = function({ fetch }) {


Lots of words. No solution. Terminology in the web page is not that used in VS.

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a3b20c46-c5f1-3a2a-738d-8aa8e69cf10c
Version Independent ID: 7055e752-859b-6106-6802-70010d0305d9
Content: NuGet Package Restore
Content Source: docs/consume-packages/Package-Restore.md
Service: nuget
GitHub Login: @JonDouglas
Microsoft Alias: jodou

I have updated from vs 2019 3 times only to find it has more issues than ever.


Problem with proxies24 source

hi
when i run example at end of output say this error :
Error: Could not find hosts HTML element.
    at Object.parseListPageHtml (/var/www/node/node_modules/proxy-lists/sources/proxies24.js:203:15)
    at /var/www/node/node_modules/async/dist/async.js:2550:16
    at /var/www/node/node_modules/async/dist/async.js:2489:9
    at replenish (/var/www/node/node_modules/async/dist/async.js:946:17)
    at iterateeCallback (/var/www/node/node_modules/async/dist/async.js:931:17)
    at /var/www/node/node_modules/async/dist/async.js:906:16
    at /var/www/node/node_modules/async/dist/async.js:2491:13
    at /var/www/node/node_modules/async/dist/async.js:2552:17
    at Request._callback (/var/www/node/node_modules/proxy-lists/sources/proxies24.js:175:4)
    at Request.self.callback (/var/www/node/node_modules/request/request.js:188:22)

my node version is
 node -v
v8.11.2

on centos 7 64 bit

Error: Missing required option (`option.bitproxies.apiKey`): You can get an API key for this service by creating an account at https://bitproxies.eu/
Error: Missing required option (`option.kingproxies.apiKey`): You can get an API key for this service by creating an account at https://kingproxies.com/register
{ Error: unable to verify the first certificate
    at TLSSocket.<anonymous> (_tls_wrap.js:1105:38)
    at emitNone (events.js:106:13)
    at TLSSocket.emit (events.js:208:7)
    at TLSSocket._finishInit (_tls_wrap.js:639:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:469:38) code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' }

You don't have the right certificates installed. See: https://www.npmjs.com/package/ssl-root-cas for possible solutions

Appears to be working now.


Allow search without mut

I am trying to make an LDAP connection and then use it concurrently to make search requests, however I'm not able to because all search APIs take &mut self. Is there any way this could be changed so that a connection can be shared across concurrent tasks?

Are you using the synchronous or the asynchronous API?

sync, but only because the docs show LdapConnAsync also returns a normal ldap3::Ldap, which is what we search with.

Ah, I just noticed the docs say Ldap can be cloned, so I assume that's the proper way of handling this. Feel free to close this if so.
Thanks! 😄

Heh, seems I'm late with the response :wink: Yes, Ldap is cheap to clone on purpose, and it's the proper way to obtain a new handle.


Improve errors from eslint

Make missing presets/invalid configuration files easier to diagnose.

Codecov Report

Merging #124 into master will increase coverage by 0.07%.
The diff coverage is 90%.

@@            Coverage Diff             @@
##           master     #124      +/-   ##
==========================================
+ Coverage   92.23%   92.31%   +0.07%
==========================================
  Files          58       58
  Lines        3105     3122      +17
==========================================
+ Hits         2864     2882      +18
+ Misses        241      240       -1

Impacted Files
Coverage Δ

lintreview/tools/eslint.py
100% <100%> (ø)
:white_check_mark:

tests/tools/test_eslint.py
100% <100%> (ø)
:white_check_mark:

lintreview/tools/init.py
90.43% <80%> (+0.86%)
:white_check_mark:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0bbc5fa...7db96c0. Read the comment docs.


Method decorators break with compilerOptions specified

Behaviour seems to be different when compilerOptions are included vs not included for decorators. This causes method decorators not to function as expected.
TypeScript Version:  3.2.0-dev.201xxxxx

#!/usr/bin/env node
var ts = require("typescript")
var fs = require("fs")
const shell = require('shelljs')

const original = `
    function logMethod(target, key, descriptor) {

        let originalMethod: () => any
        if (descriptor === undefined) {
            descriptor = Object.getOwnPropertyDescriptor(target, key)
        }
        originalMethod = descriptor.value

        // editing the descriptor/value parameter
        descriptor.value = function(...args: any[]) {
            console.log('Decorated method ' + key + ' logged with args:[' + args + '}]')
            const result = originalMethod.apply(this, args)
            return result
        }

        //Object.defineProperty(target, key, descriptor)
        // return edited descriptor as opposed to overwriting the descriptor
        return descriptor
    }

    export class Example {
        @logMethod
        public calc(x: number, y: number): number {
            return x + y;
        }
    }

    var main = function () {
        new Example().calc(5, 4);
        console.log("Finished running example");
    }()
`

const fail = (source) => {
    return ts.transpileModule(source, {compilerOptions: {}}).outputText
}

const pass = (s) => {
    return ts.transpileModule(s, {}).outputText
}

(async function () {
    let transpiledWrong, transpiledRight
    await new Promise((resolve, reject) => {
        let filesWritten = 0
        let checkFile = (err) => {
            if( ++filesWritten >= 2 )
                err ? console.log(err) : console.log("file written")
                resolve()
        }

        fs.writeFile('fail.js', transpiledWrong = fail(original), (err) => {
            checkFile(err)
        })
        fs.writeFile('pass.js', transpiledRight = pass(original), (err) => {
            checkFile(err)
        })

    })

    console.log(`
    When transpiled with an empty object passed in for the config, a null is added to the __descriptor() call below

===== Begin file out =====

${transpiledRight}
===== End file out =====

    The expected output is

        Decorated method calc logged with args:[5,4}]
        Finished running example

    The actual output follows

${shell.exec('node ./pass.js')}

    When transpiled with an object containing compilerOptions (with or without options) is passed in for the config, a null is missing from the __descriptor() call below

===== Begin file out =====

${transpiledWrong}
===== End file out =====

    The expected output is

        Decorated method calc logged with args:[5,4}]
        Finished running example

    The actual output follows

${shell.exec('node ./fail.js')}
    `)
})()

Providing a compilerOptions object overrides the defaults for transpileModule. The defaults imply target: es5 and jsx: preserve (while explicitly providing an empty object makes the target es3 and no jsx allowed). The difference in target is probably what causes the discrepancy.

Thanks for the quick response. I believe this implies that method decorators are unsupported in es3? Would you happen to know why that is the case?
I have been able to make them work by manually adding a null parameter to the __decorator() call in the js output.

I'm pretty sure it's because property descriptors aren't a thing in es3; but almost nobody uses es3 anymore~

Seems like our defaults should still be filled in.

@weswigham - Google Apps Script is still all es3 haha
Some things I played around with
Modifying the __decorator function generation code
return c > 3 && r && Object.defineProperty(target, key, r), r;
to
return c > 3 && r && Object.defineProperty(target, key, r), r;
https://github.com/Microsoft/TypeScript/blob/c2898db9dd58c9b0681d6131ed6076d71d89e6b5/src/compiler/transformers/ts.ts#L3686
Result: Works for my case, breaks all the tests
Modifying the __decorator call generation code
https://github.com/Microsoft/TypeScript/blob/c2898db9dd58c9b0681d6131ed6076d71d89e6b5/src/compiler/transformers/ts.ts#L1571
Result: Couldn't seem to get any different behavior changing any of this, but it looks like it's where the problem would be

If you need to, you can always just supply your own __decorator helper that works sufficiently well on your runtime.


Can't call constructor of a derived class

Hello, i am having a problem, when i try to call the constructor of a derived class, here the case in synthesis:
c++
class GameScreen
    {
    public:
        GameScreen();
        GameScreen(ScreenType);
    };

class MapScreen : public screen::GameScreen
    {
    public:
        MapScreen();
    };

sol::table screen_module = lua["screen"].get_or_create<sol::table>();
        screen_module.new_usertype<GameScreen>("GameScreen", sol::constructors<GameScreen(), GameScreen(ScreenType)>());

sol::table map_module = lua["map"].get_or_create<sol::table>();
        map_module.new_usertype<map::MapScreen>("MapScreen", sol::constructors<>(),
                                                sol::base_classes, sol::bases<screen::GameScreen>());

lua
-- This is OK
print("pointer to class: ", screen.MapScreen);

-- This fail
print("call constructor: ", screen.MapScreen:new());

Could i be forgetting something?
Regards

Maybe you should call screen.MapScreen.new(), so with . instead of :.
Also looks like your example code has some missing code. It is hard to know if some of it causes your problems.
I tested your example and made it work in godbolt, so you can try take a look and see how your code differs.
#define SOL_ALL_SAFETIES_ON 1
#include <sol/sol.hpp>

typedef int ScreenType;

class GameScreen {
   public:
    GameScreen() {}
    GameScreen(ScreenType) {}
};

class MapScreen : public GameScreen {
   public:
    MapScreen(){};
};

int main() {
    // Sol
    sol::state lua;
    lua.open_libraries(sol::lib::base, sol::lib::package);

    sol::table screen_module = lua["screen"].get_or_create<sol::table>();
    screen_module.new_usertype<GameScreen>(
        "GameScreen",
        sol::constructors<GameScreen(), GameScreen(ScreenType)>());

    sol::table map_module = lua["map"].get_or_create<sol::table>();
    map_module.new_usertype<MapScreen>("MapScreen", sol::constructors<MapScreen()>(),
                                       sol::base_classes,
                                       sol::bases<GameScreen>());

    lua.script("print('pointer to class: ', map.MapScreen);");
    lua.script("print('pointer to class: ', map.MapScreen.new());");

    return 0;
}


Docs Request:  Usage with a devShell

Is it possible to write a flake.nix which defines a devShell that works like so?
$ git clone github.com/some/project
$ cd project
$ nix develop
$ vim  # launches nixvim as configured by project/flake.nix

The docs seem to be about using flakes to configure your system, but I'm interested in the case where they're used to configure your project.

Using the legacyPackages.${system}.makeNixvim, you can create a nvim instance which has all its configuration bundled in it. It takes in argument a valid nixvim config and builds a package in which neovim is wrapped to use this config.
So you should be able to do something like:
  let
    vim = nixvim.legacyPackages.x86_64-linux.makeNixvim {
      plugins.lsp.enable = true;
      ...
    };
  in pkgs.mkShell {
    packages = [ vim ];
  }

You would have to launch it as nvim, not vim though.

Yeah, it's what @dwarfmaster said, but I'll be adding this to the readme

That works great, thank you!

Done!


Show mitigation policies marked in LdrSystemDllInitBlock.MitigationOptionsMap.Map[1] and [2]

Description of the feature, modification, idea or suggestion
Map[1] and [2] contains settings for loader integrity continuity, module tampering protection, XFG, CET, etc.
There is some commented out code in mtgndlg.c saying those flags aren't propagated into the array but it uses Map[0] instead of [1] (https://github.com/processhacker/processhacker/blob/master/ProcessHacker/mtgndlg.c#L212).
For some reason most of the values from WinBase.h start from the 3rd DWORD of the array (so top half of Map[1]) making parsing it a bit confusing. For example:
#define PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK              (0x00000003ui64 << 12)
This is actually bit 44 in Map[1], so the check for the bit will actually be:
(context->SystemDllInitBlock->MitigationOptionsMap.Map[1] >> 32) & PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_ALWAYS_ON.
The values of the mitigations in Map[2] is also relative to the 3rd DWORD, so for example PROCESS_CREATION_MITIGATION_POLICY2_XTENDED_CONTROL_FLOW_GUARD_MASK (x << 40) is actually (Map[2] >> 8) & PROCESS_CREATION_MITIGATION_POLICY2_XTENDED_CONTROL_FLOW_GUARD_MASK.
Proposed implementation details (optional)
No response

There is some commented out code in mtgndlg.c saying those flags aren't propagated into the array but it uses Map[0] instead of [1

They did originally use [1] when it was written in 2015 but this was changed in 2018 with commit https://github.com/processhacker/processhacker/commit/e27a46e74f6812e5c742d9f4deb72211209d155e

For some reason most of the values from WinBase.h start from the 3rd DWORD of the array (so top half of Map[1]) making parsing it a bit confusing

Was this only added in recent builds?

I didn't see these changes in master, is this in a different branch?

This was the original/old code from years ago.

I'm not sure if this change happened

I think the format/array changed a few times back then hence the changes. It's probably more stable now but I wonder how things like bit 44 in Map[1] are used with masks like 3 << 12. Why are some bits identical but others using different offsets?

From quick testing it looks like anything starting from PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK (3 << 12) is shifted by 32 bits, but PROCESS_CREATION_MITIGATION_POLICY2_LOADER_INTEGRITY_CONTINUITY_MASK and PROCESS_CREATION_MITIGATION_POLICY2_STRICT_CONTROL_FLOW_GUARD_MASK are not shifted... I still see some of the other bits in the lower DWORD of Map[1] being used, but not sure by what. I'll keep looking into it.
For example, here's the map for a process that enabled module tampering protection and loader integrity continuity:
lkd> dx ((combase!_PS_SYSTEM_DLL_INIT_BLOCK*)&ntdll!LdrSystemDllInitBlock)->MitigationOptionsMap.Map
((combase!_PS_SYSTEM_DLL_INIT_BLOCK*)&ntdll!LdrSystemDllInitBlock)->MitigationOptionsMap.Map                 [Type: unsigned __int64 [3]]
    [0]              : 0x10000000032 [Type: unsigned __int64]
    [1]              : 0x2000100000000010 [Type: unsigned __int64]
    [2]              : 0x2002202 [Type: unsigned __int64]

Bit 4 in Map[1] is enabled (for loader integrity continuity) and bit 44 in Map[1] for module tampering protection (3 << 12).


The review "red X" icon is overly scary

https://twitter.com/yaypie/status/776888659492483072
How would people feel about replacing it with something more neutral - perhaps a gray circle, like slicknet suggested?

There's a lot of things I don't like with the new review features, but on this I'm more inclined to say it's useful. A neat thing for me though would be to gray it out once the same person has approved the PR.

That happens already - when the user approves the review, the icon at the bottom of the pull request changes from a scary red X to a green circle with a checkmark.
I am only suggesting that the scary "unapproved" red X be made less angry and aggressive-looking.

@TehShrike But it doesn't mark the original review as outdated or taken care of. When multiple people are reviewing it's nice to see that a review of one person has later being approved. The notation in the bottom just shows which people approved and which don't and whether all people approved. But when looking at specific reviews in the timeline you don't know if that's taken care of.

Sure, that's fair.  I'd be in favor of that change too.
I only meant to bring up the red X to consider changing it to something less aggressive when it was displayed, but I don't know if it's worth opening a second issue to discuss these two things separately.

My comments here are less valid/needed now as GitHub now collapses review comments when the line which was commented on has been updated just like they've been doing before the new code review features. They've also introduced the ability to dismiss reviews if needed. So my problems with the code reviews are very much addressed.
On the original request of this issue I'm neutral as I don't really need it, but won't be a problem for me either.

Anyone else wants this? I don't think we should do this with all of the recent developments on PR reviews.

@hkdobrev agree it's no longer needed with the improvements they've pushed to code reviews.


Allow rewriting Response's Location header

Scenario:

User enters https://www.example.com/foo (Server1)

Server1 proxies the request to https://localhost:123/foo (Server2)

Server2 responds with 202 or 301 with header Location: https://localhost:123/bar.

Server1 forwards that header back, which when redirected, user is no longer accessing Server1.

Suggestion: add an option to allow rewriting Location header if it is present and is absolute Uri and the origin (scheme, host and port) is same as Server2's.
(I am working on it, going to create a pull request)

Please check the pull request. Usage:
            services.AddProxy(configureOptions: options =>
            {
                options.RewriteResponseLocationHeader = true;
            });

I still haven't understood your Unit Test yet so I will need your help on this. I have tested it with https://httpstat.us/301.

It appears the upstream host is not aware or using the x-forwared headers. If it uses those headers, it would generate the.correct absolute URL in the location header. Is this not the case?

@datvm I've added a test #79 that ensures the location header is correct. If your upstream host is not generating the correct URLs then it is not configured to use X-Forwarded-* headers correctly. Please see the relevant section in the documentation.
Finally, if you really want or need to to do location header rewrites do it in your proxy code. Something like...
    app.RunProxy(async context =>
    {
        var response = await context
            .ForwardTo("http://localhost:" + port + "/")
            .AddXForwardedHeaders()
            .Send();
        if (response.Headers.Location != null)
        {
            response.Headers.Location = <rewrite here>;
        }
        return response;
    }));

... which could be wrapped in an extension method.
As such, I won't be accepting your proposed change.


ARROW-16549: [C++] Simplify AggregateNodeOptions aggregates/targets

13150

 Quality gate: Passed
1 Issues

 1 Code issues

Details

 Quality gate: Passed
1 Issues

 1 Code issues

Details


Blevins 2020

Reference
doi or URL: https://doi.org/10.1098/rstb.2019.0582

All raw sequencing data generated for this project, including samples, extraction blanks and library preparation blanks, can be found under the NCBI BioProject accession PRJNA603842

Looking through the dates the samples are very recent. While are from preserved skin biopsies, some are only from 6 years ago, I would consider these to be basically modern.. For now we should stick with our 'around 1950' limit.

Sample
Geographic origin
Date isolated or radiocarbon dating

511
Samoa
2011

515
Hawai'i
2011

516
Samoa
2014

517
Guam
2014

518
Hawai'i
2011

519
Hawai'i
2014

520
Hawai'i
2015

536
Guam
2012

537
Northern Mariana Islands
1998

538
Samoa
2000

539
Northern Mariana Islands
2008

540
Northern Mariana Islands
1998

542
Palau
2000

543
Palau
2002

523A1
Hawai'i
2008


How to make player sprites go behind opponent?

Describe your problem here.
Hi!
Is there any kind of Lua script I can use to make the player character go behind the opponent for a single song?
I don't really know any code so if anyone can help me out, I'll be extremely grateful.
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

https://github.com/ShadowMario/FNF-PsychEngine/wiki/Lua-Script-API:-Object-Functions#object-orderremoving

forgot to close this but I got it. Thank you so much for helping me!


Chrome driver error

I haven't seen Run-time error 0 here so I'm posting. Using Selenium 2.0.9.
The code:
Dim bot As New FirefoxDriver
bot.Start "chrome"

Throws:
Run-time error 0: WebRequestError, Connection stopped, Unexpected error
It opens the Chrome browser, I've checked the version:
58.0.3029.81 (64-bit)
I guess it's still the same issue as with firefox - downgrade the driver. I'm not sure which version should I use n this case. I use RSelenium with RStudio and it works wit all versions on several browsers. Why this wrapper is worse that that?

Ok. I've had to install newest driver for chrome from 3-rd party unlike the FF. Sorry, haven't read all posts.

hi,rafaleo!
I used Selenium for the first time , And I used in VBA .
After I install The EXE file(SeleniumBasic-<IP_ADDRESS>.exe),
I referended the "Selenium Type Library" in VBA Project.
Then I run this code :
Private Sub Use_Chrome()   Dim driver As New ChromeDriver   driver.Get "https://www.google.co.uk"   driver.Quit End Sub
It opened Google's browser, Then pop-up prompts "chromedriver.exe stopped working",Address bar says "data;,"
And Program throws this error:
"Run-time error 0: WebRequestError , Underlying connection closed: error occurred while receiving"
My Chrome's Version is 59.0.3071.104 (32bit)
I really don't know how to handle it , I would appreciate it if you could tell me what to do.

You may have a conflict between your version of Chrome and your version of
Chromedriver that came with SeleniumBasic-<IP_ADDRESS> which is pretty old to
start with.
I would recommend you upgrade Chrome to the latest version (66.xxx) and
install the latest Chromedriver available at
https://sites.google.com/a/chromium.org/chromedriver/
To install the Chromedriver, just download the zip file and extract the
content (Chromedriver.exe) to your SeleniumBasic installation folder to
replace the existing file Chromedriver.exe
From time to time as my Chrome browser is updated, I also run into
unexpected issues with SeleniumBasic for functions that used to work fine.
But every time I have such issues, I simply update the Chromedriver.exe and
all works perfectly fine again.
On 13 June 2018 at 12:29, Elkn<EMAIL_ADDRESS>wrote:

hi,rafaleo!
I used Selenium for the first time , And I used in VBA .
After I install The EXE file(SeleniumBasic-<IP_ADDRESS>.exe),
I referended the "Selenium Type Library" in VBA Project.
Then I run this code :
Private Sub Use_Chrome() Dim driver As New ChromeDriver driver.Get "
https://www.google.co.uk" driver.Quit End Sub
It opened Google's browser, Then pop-up prompts "chromedriver.exe stopped
working",Address bar says "data;,"
And Program throws this error:
"Run-time error 0: WebRequestError , Underlying connection closed: error
occurred while receiving"
My Chrome's Version is 59.0.3071.104 (32bit)
I really don't know how to handle it , I would appreciate it if you could
tell me what to do.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/florentbr/SeleniumBasic/issues/143#issuecomment-396891231,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJlnWgY6vHobaUoYTu1M3tBREO45Aqceks5t8OmOgaJpZM4NDKrd
.

@Jottie Thanks so much!
I downloaded the matching version driver and chrome,  and now , it work!
(I can't access your Web site, but I downloaded the chromedriver from other web site)
Thanks again~ : )
PS:The following is the version of chromeDriver to Chrome, and the chromedriver Download address. Hope to be useful to others.
http://chromedriver.storage.googleapis.com/index.html
ChromeDriver | Chrome
v2.39 | v66-68
v2.38 | v65-67
v2.37 | v64-66
v2.36 | v63-65
v2.35 | v62-64
v2.34 | v61-63
v2.33 | v60-62
v2.32 | v59-61
v2.31 | v58-60
v2.30 | v58-60
v2.29 | v56-58
v2.28 | v55-57
v2.27 | v54-56
v2.26 | v53-55
v2.25 | v53-55
v2.24 | v52-54
v2.23 | v51-53
v2.22 | v49-52
v2.21 | v46-50
v2.20 | v43-48
v2.19 | v43-47
v2.18 | v43-46
v2.17 | v42-43
v2.13 | v42-45
v2.15 | v40-43
v2.14 | v39-42
v2.13 | v38-41
v2.12 | v36-40
v2.11 | v36-40
v2.10 | v33-36


Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late!
mardix, @joedooley, @qustavo, @mxuribe, @ertygiq, @changliang0931, @537, @heX16, @geeksambhu, @Ecno92, @krayzedpinoy, @jonar06, @GitTorres, @onewesong, @ryanio, @lisboaxd, @donnellan0007, @ruigomeseu, @red2342, @holbewoner, @rohit-nair, @akhan3, @ZelnickB, @lyoshenka, @Gbfiness, @JoaquinMVR, @eirunye, @selftaught, @iotatau, @VFaleiro, @5toliv, @joemphilips, @vsiryxm, @rcline112, @mio4, @Dragankamil6, @weeksco, @volumnia, @frederikstroem, @fighterleslie, @ozworkz, @gsilvan, @SreeChandan, @idunno101, @leejw51, @dethos, @ahoebeke, @Danyalkasiri, @AdamBouhmad, @wellington1993

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late! mardix, @joedooley, @qustavo, @mxuribe, @ertygiq, @changliang0931, @537, @heX16, @geeksambhu, @Ecno92, @krayzedpinoy, @jonar06, @GitTorres, @onewesong, @ryanio, @lisboaxd, @donnellan0007, @ruigomeseu, @red2342, @holbewoner, @rohit-nair, @akhan3, @ZelnickB, @lyoshenka, @Gbfiness, @JoaquinMVR, @eirunye, @selftaught, @iotatau, @VFaleiro, @5toliv, @joemphilips, @vsiryxm, @rcline112, @mio4, @Dragankamil6, @weeksco, @volumnia, @frederikstroem, @fighterleslie, @ozworkz, @gsilvan, @SreeChandan, @idunno101, @leejw51, @dethos, @ahoebeke, @Danyalkasiri, @AdamBouhmad, @wellington1993

dm me I like your offer


There must be a way to provide Babel options

Hello! Thanks for the awesome project.
I found the feature https://github.com/TypeStrong/atom-typescript/pull/475 with optional babel support very useful. But it seems incomplete to me, because there must be a way to specify Babel's options. Existed solutions like https://babeljs.io/docs/usage/babelrc/ don't work (or I'm doing something wrong).

Maybe we can offer the second extended form of the externalTranspiler option?
"externalTranspiler": {
	name: "babel",
	options: {
		/* babel options goes here */
	}
}

Or maybe there is a way to make .babelrc work?

Maybe we can offer the second extended form of the externalTranspiler option

I like the simplicity of this :rose:
Closed by https://github.com/TypeStrong/atom-typescript/pull/523

How does this work? I set this, I have babel installed in my node_modeuls dir, yet no transpilation with babel hapens. Also, the options are not available, I need to use babel plugins.

@tomitrescak personally I've never used this option so can't be much help. With the TypeScript compiler getting a transformer based emitter soon, we wouldn't need to offload heavy plug-gable emitting to babel hopefully :rose:
Still docs https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md#can-i-use-an-alternate-transpiler

It calls Babel on the emitted result before writing it to disk.  This was a bit of a hack to get let for loops working pre-1.8 and it includes babel 5.  Look at the referenced PR.


Support custom categories and add VariablesCategory

This adds support for labels and buttons to the flyouts and sets up a
way to create custom categories. It also adds a custom category for
variables that dynamically builds the blocks for the variables
category.

This change is

Reviewed 16 of 19 files at r2.
Review status: 16 of 19 files reviewed at latest revision, 6 unresolved discussions.

blocklylib-core/src/main/java/com/google/blockly/android/control/FlyoutController.java, line 63 at r2 (raw file):

        @Override
        public void onButtonClicked(View v, String action, FlyoutCategory category) {
            // TODO (#503): Switch to using the view's tag to determine behavior

"view's tag" => "action string"

blocklylib-core/src/main/java/com/google/blockly/android/control/VariableCategory.java, line 32 at r2 (raw file):

 * Automatically adds/removes blocks from the category when the list of variables changes.
 */
public class VariableCategory extends FlyoutCategory {

See VariableFlyoutFactory comments.

blocklylib-core/src/main/java/com/google/blockly/android/ui/CategoryTabs.java, line 316 at r2 (raw file):

     * Callback for when the user clicks on a category.
     */
    public abstract static class Callback {

Search isn't finding any other instance of "onCategoryClicked" or "CategoryTabs.Callback". Is this used?

blocklylib-core/src/main/java/com/google/blockly/model/CategoryFactory.java, line 29 at r2 (raw file):

    public abstract FlyoutCategory obtainFlyout(String customType);

    public static final class VariableFlyoutFactory extends CategoryFactory {

Rename VariableCategoryFactory.
It seems like everything in VariableCategory could be put here.  It doesn't seem to me like we should expect developers to extend two classes, and extending the data structure (FlyoutCategory) doesn't seem right.
In which case, it would become large enough to be  top level class.
Also, was "final" intentional? Not that I see a reason to extend this class. I'm okay with it if it was intentional.

blocklylib-core/src/main/java/com/google/blockly/model/FlyoutCategory.java, line 321 at r2 (raw file):

     * Wraps items that can be displayed as part of a {@link FlyoutCategory}.
     */
    public abstract static class FlyoutItem {

CategoryItem?  (Flyout implies a particular drawer-like UI to me)

blocklylib-core/src/main/java/com/google/blockly/model/FlyoutCategory.java, line 359 at r2 (raw file):

    /**
     * Flyout item representing a clickable button, such as "Add Variable".
     * TODO (#503): Support style and callback spec

I think the style spec was web/CSS specific. Hence "web-class". (For all of the discussions, why didn't we choose css-class?).

Comments from Reviewable

Review status: 16 of 19 files reviewed at latest revision, 6 unresolved discussions.

blocklylib-core/src/main/java/com/google/blockly/android/control/FlyoutController.java, line 63 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
"view's tag" => "action string"

Removed.

blocklylib-core/src/main/java/com/google/blockly/android/ui/CategoryTabs.java, line 316 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
Search isn't finding any other instance of "onCategoryClicked" or "CategoryTabs.Callback". Is this used?

Done.

blocklylib-core/src/main/java/com/google/blockly/model/CategoryFactory.java, line 29 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
Rename VariableCategoryFactory.
It seems like everything in VariableCategory could be put here.  It doesn't seem to me like we should expect developers to extend two classes, and extending the data structure (FlyoutCategory) doesn't seem right.
In which case, it would become large enough to be  top level class.
Also, was "final" intentional? Not that I see a reason to extend this class. I'm okay with it if it was intentional.

I'm not sure I understand how it would work as a single class. You still need a generic method to build new instances of the category, which can't be a static method because it may need additional information depending on implementation. Also, the category itself can be dynamic, so the list of items can't just be set at creation.
I could conceivably make CategoryFactory an interface that VariableCategory implements with obtainCategory just returning itself, but in general I can't assume the factory doesn't return a unique instance for each obtain call.
Making it final was intentional. It's a simple enough class I wanted to be clear this is a default implementation and devs should just create their own to replace it.

blocklylib-core/src/main/java/com/google/blockly/model/FlyoutCategory.java, line 321 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
CategoryItem?  (Flyout implies a particular drawer-like UI to me)

I also renamed the top level class to BlocklyCategory

blocklylib-core/src/main/java/com/google/blockly/model/FlyoutCategory.java, line 359 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
I think the style spec was web/CSS specific. Hence "web-class". (For all of the discussions, why didn't we choose css-class?).

I think css-class was too confusing. I still need to add support for buttons in XML and their action tag and eventually some form of styling.

Comments from Reviewable

Reviewed 5 of 15 files at r3.
Review status: 16 of 25 files reviewed at latest revision, 2 unresolved discussions.

blocklylib-core/src/main/java/com/google/blockly/model/CategoryFactory.java, line 29 at r2 (raw file):
Previously, RoboErikG wrote…
I'm not sure I understand how it would work as a single class. You still need a generic method to build new instances of the category, which can't be a static method because it may need additional information depending on implementation. Also, the category itself can be dynamic, so the list of items can't just be set at creation.
I could conceivably make CategoryFactory an interface that VariableCategory implements with obtainCategory just returning itself, but in general I can't assume the factory doesn't return a unique instance for each obtain call.
Making it final was intentional. It's a simple enough class I wanted to be clear this is a default implementation and devs should just create their own to replace it.

I'm not grasping your usage of "generic method".
I imagine a single factory object for each custom string will be created, and the factory will create an instance (either once, or on demand) of the category's contents. The DatasetObserver for the variables can be registered during that creation, and update the category, as long as methods are added to modify the category, so I don't see that as a barrier.

Comments from Reviewable

There is enough good stuff here, if you want to commit and iterate later.  Let me know if you have further questions about the factory.

Review status: 16 of 25 files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

Oh, I see what you mean! I'll do a followup change for that so I can reduce the merge noise.

Review status: 16 of 25 files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

Review status: 16 of 25 files reviewed at latest revision, 2 unresolved discussions.

blocklylib-core/src/main/java/com/google/blockly/model/CategoryFactory.java, line 29 at r2 (raw file):
Previously, AnmAtAnm (Andrew n marshall) wrote…
I'm not grasping your usage of "generic method".
I imagine a single factory object for each custom string will be created, and the factory will create an instance (either once, or on demand) of the category's contents. The DatasetObserver for the variables can be registered during that creation, and update the category, as long as methods are added to modify the category, so I don't see that as a barrier.

I understand now. Will followup with another CL to make this change.

Comments from Reviewable


wait for release before post hooks

What this PR does / why we need it:
If a release has post-install, post-delete, or post-rollback hooks, always wait for the main resources before doing the post - otherwise it's not really "post". This ensures that the behavior is correct if a chart user doesn't apply the --wait flag when a chart has "post" operations.
This was seen in the wild when one of our (Redpanda) chart users installed without the --wait flag and the post-install configuration failed because the statefulset wasn't ready to accept connections from the post-install,post-upgrade job. We never caught this in CI because ct always sets the --wait flag.
Fixes #11778
Special notes for your reviewer:
https://github.com/helm/chart-testing always tests with the --wait flag so this is a no-op for charts that are tested. In fact, this ensures the user has the same experience as the test if the user fails to set wait.
If applicable:

[ ] this PR contains documentation
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

While technically this can be breaking (let's say a Chart contains a Deployment and a Job, the Job is marked as post-install and the Deployment mounts e.g. some secret generated by the Job) I'm still in favor of this change.
It only breaks Charts that were already more-or-less broken, as they can't be installed with --wait enabled either.

To elaborate on @phil9909's scenario:

Chart creates a Deployment and a Job. The Job is marked as post-install hook
Deployment attempts to create pod(s), but these fail because they depend on a missing secret
-- Helm would never successfully wait at this point --
The post-install Job runs, and creates the secret
The Deployment retries, and pod(s) successfully are created

Notably (as @phil9909 mentions), a chart relying on the above would be broken by the wait functionality (Point 3)

The awkwardness of the above scenarios, IMHO is that charts can either be broken by --wait, or require it! I think helm should pick a side (which e.g. this PR does).
Personally (sample size 1; so perhaps to be taken with a grain of salt), I've only ever seen helm used with --wait. Since synchronizing the helm invocation with the state of the world, reporting errors, etc provides great utility (I would be in favor of enabling wait by default). I have not used post-install|upgrade|rollback hooks. But their usage to act on the completed deployment seems to be the most relevant.
So, given the utility of --wait, I think helm should choose to be consistent and wait in the presence of a post-install|upgrade|rollback hook. And so in favor of this PRs logic.
For the case of where someone could (successfully) be taking advantage of post-install|upgrade hooks running before the deployed is considered successfull. e.g @phil9909 scenario. I wonder if we need to add an option (or another hook type :( ) to retain this behavior?


Catching exceptions and build scripts fix

rmsauth_sample uses rmsauth lib which links to rmscrypto lib
It doen't work on Ubuntu without linking!

This block is not necessary now because of catching crypto exceptions inside rmsauth library.


UI issues of different screen:

Heading should be: Setting up the Inheritance Key.

I should be capital of Inheritance.

Need a different line

Recovery spelling

fixed


Retrieve call URL before we make the request

@JakeWharton
For Call, we can do the following without making an actual request
call.request().url().toString()
how do we do the same for Deferred?

You cannot. Calling the method will always send the request.


vulnerability: Remote Memory Exposure

To avoid Remote Memory Exposure vulnerability
please update tar-fs package
npm i<EMAIL_ADDRESS>

https://github.com/prebuild/prebuild-install/blob/9e62565f5847d5fad887112969c13df57e96f0a8/package.json#L35

Thanks for your help
delete yarn.lock file and run yarn fix the problem


Header Styling

Rename ShotBot to Record Checker for now
Change background color to match footer, #3a3a3c
Change 'Sign In' link to 'Sign Out' (the only page that can be viewed while signed out is the sign in page, which does not need a link to itself).

Resolved, finished by @racheledelman before monday show to Jelene and Ms. Barbara


chore: add open telemetry tracing

Changes

extract node-cosmos package (closed source) from onfinality/subql-node-cosmos image
add OpenTelemetry instrumentation to node-cosmos package

additional effort is required to trace through the vm2 sandbox environment (i.e. distinguishing our mapping handler functions)

add OpenTelemetry dependencies to subql-node-cosmos container
add package.json scripts to start (and stop) the tracing docker composition
add SigNoz stack to new tracing docker composition (path of least resistance)

in production environments, we will have to either:

replicate this in helm charts
(or) reconfigure OpenTelemetry to report to existing grafana / prometheus / loki stack

Not sure why auto-merge decided to go ahead before CI finished... :thinking:


Scrape tradingview ideas (or follow people on there)

TradingView also has some kind of social platform called ideas, where we could also follow users

Can this be scraped?


Add recip, angle and angle_between methods to Vector2F

@bors-servo: r+

:pushpin: Commit 7b244ca has been approved by pcwalton

:hourglass: Testing commit 7b244cad68154e31792a7692d4f21c5177f56fc3 with merge 72a9deed9febc5f97c561736418c9ca6d5655ea8...

:sunny: Test successful - checks-travis
Approved by: pcwalton
Pushing 72a9deed9febc5f97c561736418c9ca6d5655ea8 to master...


Add JSON button to trace detail view

The screenshot on zipkin.io includes a blue JSON button which is a link to /api/v1/trace/id. This would be very helpful when folks are trying to debug problems, as manually instructing is not intuitive.

It should be possible to add this in trace.mustache, I think.
Something like JSON