Rare and random crash in bn_sqr8x_internal

Since few months we are getting some crash dumps in our Instant Messenger application (GaduGadu - www.gg.pl). It happens rarely - average like once per 2 weeks - so it is not so big problem and we tried to wait it out hoping for fix in a new version, but there isn't any. We have really huge traffic (50 logins per second, 100 000 simultaneous connections) and it happens so rarely, that it looks like some race condition or strange data, which can randomly triggers it. It is hard to say what change caused begin of these crashes, because we changed few things at once (like: OpenSSL version 1.0 -> 1.1.1, new ciphers and support for TLS 1.2, our new certificate) and sometimes interval between crashes is one month or longer, so it is difficult to debug and it is in production environment, so we can't afford to undo all changes and wait for months. We are using OpenSSL for 10 years or more and never had such problems. It started +/- about 10 months ago, and looking at all what I have written, I'm sure that it isn't a problem in our code.
So now some details about our environment. We are using manually built Debian package in version 1.1.1h (built with symbols and full debug information for debugging this issue, but crash happens on earlier versions of 1.1.1 - we started using 1.1.1 from 1.1.1d) and our application run on Jessie Debian distribution.
Kernel version: Linux version 3.16.0-4-amd64<EMAIL_ADDRESS>(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u1 (2016-10-10)
Cipher string for old versions of our application: ECDHE;AES;!EXP;!eNULL;!aNULL
Cipher string for new versions of our application: ECDHE;ECDH;AES;ECDSA;DHE;AESGCM;CHACHA20;!eNULL;!aNULL;!SHA1;!SHA256;!RSA
It looks like crash is occuring on both cipher strings.
And here is stacktrace from dump:
#0  0x00007f952c754067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f952c755448 in __GI_abort () at abort.c:89
#2  0x00007f95309caea2 in signal_core (signum=<optimized out>, si=<optimized out>, arg=0x6) at /var/SVN/server-side/engine/branches/stable/c/linux/signal.c:144
#3  <signal handler called>
#4  bn_sqr8x_internal () at crypto/bn/x86_64-mont5.s:1762
#5  0x00007f952e7ef579 in bn_power5 () at crypto/bn/x86_64-mont5.s:1177
#6  0x00007f952e7d6a35 in BN_mod_exp_mont_consttime (rr=0x7f94f6244878, a=0x7f94f6244878, p=0x28b1010, m=0x28b0eb0, ctx=0x7f94f7ebda30, in_mont=0x7f94e8014af0) at crypto/bn/bn_exp.c:1007
#7  0x00007f952e8fb576 in rsa_ossl_mod_exp (r0=0x7f94f6244848, I=0x7f94f6244830, rsa=0x28b0310, ctx=0x7f94f7ebda30) at crypto/rsa/rsa_ossl.c:677
#8  0x00007f952e8fa594 in rsa_ossl_private_encrypt (flen=51, from=0x7f94f5a322a0 "010\r\006\t`\206H\001e\003\004\002\001\005",
    to=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", rsa=0x28b0310, padding=1) at crypto/rsa/rsa_ossl.c:316
#9  0x00007f952e8f616b in RSA_private_encrypt (flen=51, from=0x7f94f5a322a0 "010\r\006\t`\206H\001e\003\004\002\001\005",
    to=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", rsa=0x28b0310, padding=1) at crypto/rsa/rsa_crpt.c:36
#10 0x00007f952e8ff9ae in RSA_sign (type=672, m=0x7f94c27f24b0 "\353\314\345Y\206\276\252R'\371\216w\307Y\276\236\023E\252ὧ\243\253\064\220meܙD3 %\177\302\224\177", m_len=32,
    sigret=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", siglen=0x7f94c27f2400, rsa=0x28b0310) at crypto/rsa/rsa_sign.c:103
#11 0x00007f952e8fcfcf in pkey_rsa_sign (ctx=0x7f94f553da50,
    sig=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", siglen=0x7f94c27f2588, tbs=0x7f94c27f24b0 "\353\314\345Y\206\276\252R'\371\216w\307Y\276\236\023E\252ὧ\243\253\064\220meܙD3 %\177\302\224\177", tbslen=32) at crypto/rsa/rsa_pmeth.c:163
#12 0x00007f952e8af5e6 in EVP_PKEY_sign (ctx=0x7f94f553da50,
    sig=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", siglen=0x7f94c27f2588, tbs=0x7f94c27f24b0 "\353\314\345Y\206\276\252R'\371\216w\307Y\276\236\023E\252ὧ\243\253\064\220meܙD3 %\177\302\224\177", tbslen=32) at crypto/evp/pmeth_fn.c:66
#13 0x00007f952e8ab4d8 in EVP_DigestSignFinal (ctx=0x7f9465d76270,
    sigret=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", siglen=0x7f94c27f2588) at crypto/evp/m_sigver.c:148
#14 0x00007f952e8ab605 in EVP_DigestSign (ctx=0x7f9465d76270,
    sigret=0x7f94f7f8719d "\003U\004\n\023\031Unizeto Technologies S.A.1'0%\006\003U\004\v\023\036Certum Certification Authority1)0'\006\003U\004\003\023 Certum Domain Validation CA SHA20\036\027\r200930000000Z\027\r210930000000Z0\031\061\027\060\025\006\003U\004\003\f\016*.gadu-gadu.pl0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", siglen=0x7f94c27f2588,
    tbs=0x7f9464bb3a00 "\a\003\017\035\062\060\346\066\235\353,33i\002ɤ\251\245\327\273\fСO*r4\306\327\217ŢxL2y\034\273\230\220R\203۾\035\231\376E\276\360\236\243\067\303KDOWNGRD\001\003", tbslen=133) at crypto/evp/m_sigver.c:170
#15 0x00007f952ecb60db in tls_construct_server_key_exchange (s=0x7f94ec75e090, pkt=0x7f94c27f26c0) at ssl/statem/statem_srvr.c:2825
#16 0x00007f952ec9f57b in write_state_machine (s=0x7f94ec75e090) at ssl/statem/statem.c:843
#17 0x00007f952ec9ea26 in state_machine (s=0x7f94ec75e090, server=1) at ssl/statem/statem.c:443
#18 0x00007f952ec9e50a in ossl_statem_accept (s=0x7f94ec75e090) at ssl/statem/statem.c:255
#19 0x00007f952ec66dd6 in ssl3_read_bytes (s=0x7f94ec75e090, type=23, recvd_type=0x0, buf=0x7f94c27f2a00 "", len=4096, peek=0, readbytes=0x7f94c27f29e0) at ssl/record/rec_layer_s3.c:1278
#20 0x00007f952ec735db in ssl3_read_internal (s=0x7f94ec75e090, buf=0x7f94c27f2a00, len=4096, peek=0, readbytes=0x7f94c27f29e0) at ssl/s3_lib.c:4473
#21 0x00007f952ec736b2 in ssl3_read (s=0x7f94ec75e090, buf=0x7f94c27f2a00, len=4096, readbytes=0x7f94c27f29e0) at ssl/s3_lib.c:4497
#22 0x00007f952ec81a15 in ssl_read_internal (s=0x7f94ec75e090, buf=0x7f94c27f2a00, num=4096, readbytes=0x7f94c27f29e0) at ssl/ssl_lib.c:1763
#23 0x00007f952ec81a72 in SSL_read (s=0x7f94ec75e090, buf=0x7f94c27f2a00, num=4096) at ssl/ssl_lib.c:1777
#24 0x00007f95309ce3d0 in ssl_handler_read (socket=0x7f947769cac0, current=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/ssl.c:197
#25 0x00007f95309c1cb6 in handler_call_stack_param (socket=0x7f947769cac0, aspect=<optimized out>, param=0x0) at /var/SVN/server-side/engine/branches/stable/c/cclib/handler.c:176
#26 0x00007f95309c71b7 in thread_worker_oper (e=<optimized out>, td=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:577
#27 0x00007f95309c6460 in thread_worker (thread=<optimized out>, data=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:774
#28 0x00007f952cad20a4 in start_thread (arg=0x7f94c27f4700) at pthread_create.c:309
#29 0x00007f952c80787d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

I can send more info if needed.
It will be nice if You can fix this crash, but eventually we can live without it. At least until it starts to happen more often...

There are (IIRC) some cases where "normal usage" of an RSA key object can result in writes to its member fields (e.g., CRT coefficients), and so the thread-safety of such usage is a bit "exciting" to analyze.  It would be good if you could say something about the threading structure of your program, how many SSL_CTXs are in use, whether each SSL gets a dedicated thread, and how the key+certificate are configured, to give a general sense of how the threads would be using the RSA object(s).

Unless otherwise documented, no object within OpenSSL can be used safely in multiple threads.
Where and how should we document this.  A new man3/openssl-intro.pod file?

I'll try to analyze threading and sharing objects throughoutly, when I will have time. We have quite complex library for thread pooling, etc. I did it once earlier, because crashes occured after migration from 1.0 to 1.1 and I had to fix this in code and then I analyzed whole our library/wrapper for OpenSSL line by line.

I'll try to analyze threading and sharing objects throughoutly, when I will have time. We have quite complex library for thread pooling, etc. I did it once earlier, because crashes occured after migration from 1.0 to 1.1 and I had to fix this in code and then I analyzed whole our library/wrapper for OpenSSL line by line.

What would be useful is to know which version of OpenSSL did not have this issue you are seeing and then see if you can try the version of x86_64-mont5.s from that version to see if that isolates it to changes in that file (or not). That at least would provide another data point.
It would also be useful to have a stack traceback of all threads at the time of the crash you are seeing - that may provide more information.

What would be useful is to know which version of OpenSSL did not have this issue you are seeing and then see if you can try the version of x86_64-mont5.s from that version to see if that isolates it to changes in that file (or not). That at least would provide another data point.
It would also be useful to have a stack traceback of all threads at the time of the crash you are seeing - that may provide more information.

Unless otherwise documented, no object within OpenSSL can be used safely in multiple threads.

Agreed that this should be documented, but an RSA object should be safe to use concurrently. Every multi-threaded TLS server does this.

There are (IIRC) some cases where "normal usage" of an RSA key object can result in writes to its member fields (e.g., CRT coefficients), and so the thread-safety of such usage is a bit "exciting" to analyze.

Unless that recently changed, it shouldn't write to CRT coefficients. RSA objects do sadly lazily compute Montgomery contexts (as consequence of #5158), but that should all be locked. (All the more reason why you'd want to share the key across threads, so that data is only computed once.)

Unless otherwise documented, no object within OpenSSL can be used safely in multiple threads.

Agreed that this should be documented, but an RSA object should be safe to use concurrently. Every multi-threaded TLS server does this.

There are (IIRC) some cases where "normal usage" of an RSA key object can result in writes to its member fields (e.g., CRT coefficients), and so the thread-safety of such usage is a bit "exciting" to analyze.

Unless that recently changed, it shouldn't write to CRT coefficients. RSA objects do sadly lazily compute Montgomery contexts (as consequence of #5158), but that should all be locked. (All the more reason why you'd want to share the key across threads, so that data is only computed once.)

#13788 has a manpage on threads and openssl.

I ended up writing text like this for BoringSSL:
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/rsa.h#76
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/evp.h#84
And then for the various functions "ought to be" const, but aren't for silly reasons (RSA_METHOD, refcounts, etc.), I added some other sentences. (Although now that I look at evp.h again, I think I missed a few spots.)
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/rsa.h#281
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/rsa.h#92
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/evp.h#98
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/evp.h#281
In particular, while it ought to be safe for two threads to use a key concurrently, you can't concurrently mutate the key while doing anything else with it. (Insert usual grumbling that most of these objects shouldn't have been mutable. :-) ) So it needs to be slightly more precise than saying concurrent access is okay.

Thanks for the pointers.  I added some general text about mutability and safety in #13788.

Thanks for the pointers.  I added some general text about mutability and safety in #13788.

Finally, I found time to analyze it. By the way, for whole month we haven't got any crashes and recently 2 crashes occured.
We are creating SSL_CTX instances and initializes whole SSL on program startup in single thread. Then we are creating SSL instances when accepting socket and all usages of SSL instance are synchronized - only one thread can operate simultaneously on socket (it gets locked for each read/write/close operations). But we don't sychronize calling SSL_new on context - maybe this is a problem? Beside this, we don't use any more objects from OpenSSL directly and don't make any unusual things.
Additionally we have callback registered via SSL_CTX_set_tlsext_status_cb - we make OCSP stapling there - and have a thread to refresh OCSP status, but this is synchronized.
As to other questions. I checked all threads in core and no other thread is doing something with SSL during crash. I can't say exactly from which version problems started (and can't check it now), but it was probably after moving from 1.0.x to 1.1.1 version (we started from 1.1.1c) or after upgrade from 1.1.1c to 1.1.1f.

The interesting thing is that the signal is SIGABRT not SIGSEGV so the question is what is triggering the signal. It might not even be the actual code where the signal is received.

No, it is SIGBUS - P2001      Core    Bus error (bad memory access):
And part from logs:
Dec 11 22:05:49 im-ggproxy-13 ggproxy[9561]: [TID c27f4700] FATAL: signal_core: received signal 7 (Bus error) Dec 11 22:05:49 im-ggproxy-13 ggproxy[9561]: [TID c27f4700] FATAL: signal_core: errno 0 (Success), si_code 128 (unknown)

Also I see, that there is one thing missing - si_addr value for this signal. It is optimized in core and I don't have it in logs. I added this to logs to have this value next time.

Finally next crash comes (now on 1.1.1j version of OpenSSL library - I upgraded it recently), so I have this si_addr now (it is this "offending address: 0x0"):
Mar 20 10:57:01 im-ggproxy-17 ggproxy[21251]: [TID 6f7de700] FATAL: signal_core: received signal 7 (Bus error)
Mar 20 10:57:01 im-ggproxy-17 ggproxy[21251]: [TID 6f7de700] FATAL: signal_core: errno 0 (Success), si_code 128 (The kernel)
Mar 20 10:57:01 im-ggproxy-17 ggproxy[21251]: [TID 6f7de700] FATAL: signal_core: offending address: 0x0

I'm also putting stacktrace for this crash:
#0  0x00007fcada49d067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fcada49e448 in __GI_abort () at abort.c:89
#2  0x00007fcade713eee in signal_core (signum=<optimized out>, si=<optimized out>, arg=0x6) at /var/SVN/server-side/engine/branches/stable/c/linux/signal.c:140
#3  <signal handler called>
#4  bn_sqr8x_internal () at crypto/bn/x86_64-mont5.s:1762
#5  0x00007fcadc53861b in bn_power5 () at crypto/bn/x86_64-mont5.s:1171
#6  0x00007fcadc51faf5 in BN_mod_exp_mont_consttime (rr=0x7fca9916ec38, a=0x7fca9916ec38, p=0x3b376e0, m=0x3b353d0, ctx=0x7fca0c2e83a0, in_mont=0x7fcac001f260) at crypto/bn/bn_exp.c:1007
#7  0x00007fcadc6445d0 in rsa_ossl_mod_exp (r0=0x7fca9916ebd8, I=0x7fca9916ebc0, rsa=0x3b36910, ctx=0x7fca0c2e83a0) at crypto/rsa/rsa_ossl.c:671
#8  0x00007fcadc643694 in rsa_ossl_private_encrypt (flen=256,
    from=0x7fca9910bfc0 "j:\252\253\177\213\222\237\261\255m\273\063`\276\021\236HsB\024\003\365Ma0E\213\017\203\260\240\067VVV\306P\264\207\212\341\200\351\036\361$-)\241\312r\233\204p\266\330ɔ\023\205\343x\324\364Z\265\342ʡq\323(r\307MV\244\037\034\002\234\222\253\225\351\304-[\375\030)\232\276h8Y\372&\351\035\177C\362\246\303\034J\372\242h\356$\236\033\vՐ\202g\264\353ΘreP\321țZ\216\233\301%\020\213\252\334 D\f\"\230\377\023\221,\202\263\257\361\033⓮\307\314\344\321\375\246w\250\261VP\256{ʃ\204\303\016,\032jt\006\066ۍS\261\252\212\305b\353\235F\226(t\333\320/\274[\032"..., to=0x7fca9910bc90 "\250\004", rsa=0x3b36910, padding=3) at crypto/rsa/rsa_ossl.c:316
#9  0x00007fcadc63f26b in RSA_private_encrypt (flen=256,
    from=0x7fca9910bfc0 "j:\252\253\177\213\222\237\261\255m\273\063`\276\021\236HsB\024\003\365Ma0E\213\017\203\260\240\067VVV\306P\264\207\212\341\200\351\036\361$-)\241\312r\233\204p\266\330ɔ\023\205\343x\324\364Z\265\342ʡq\323(r\307MV\244\037\034\002\234\222\253\225\351\304-[\375\030)\232\276h8Y\372&\351\035\177C\362\246\303\034J\372\242h\356$\236\033\vՐ\202g\264\353ΘreP\321țZ\216\233\301%\020\213\252\334 D\f\"\230\377\023\221,\202\263\257\361\033⓮\307\314\344\321\375\246w\250\261VP\256{ʃ\204\303\016,\032jt\006\066ۍS\261\252\212\305b\353\235F\226(t\333\320/\274[\032"..., to=0x7fca9910bc90 "\250\004", rsa=0x3b36910, padding=3) at crypto/rsa/rsa_crpt.c:36
#10 0x00007fcadc646192 in pkey_rsa_sign (ctx=0x7fca9beb3510, sig=0x7fca9910bc90 "\250\004", siglen=0x7fca6f7dc658, tbs=0x7fca6f7dc4d0 "̄#\263\060\023afr\024\221\\\023\351Џ\213\066\201\263@\353\t\243\206", tbslen=32) at crypto/rsa/rsa_pmeth.c:176
#11 0x00007fcadc5f8671 in EVP_PKEY_sign (ctx=0x7fca9beb3510, sig=0x7fca9910bc90 "\250\004", siglen=0x7fca6f7dc658, tbs=0x7fca6f7dc4d0 "̄#\263\060\023afr\024\221\\\023\351Џ\213\066\201\263@\353\t\243\206", tbslen=32) at crypto/evp/pmeth_fn.c:66
#12 0x00007fcadc5f4563 in EVP_DigestSignFinal (ctx=0x7fca0c2e89d0, sigret=0x7fca9910bc90 "\250\004", siglen=0x7fca6f7dc658) at crypto/evp/m_sigver.c:148
#13 0x00007fcadc5f4690 in EVP_DigestSign (ctx=0x7fca0c2e89d0, sigret=0x7fca9910bc90 "\250\004", siglen=0x7fca6f7dc658, tbs=0x7fca6f7dc5a0 ' ' <repeats 64 times>, "TLS 1.3, server CertificateVerify", tbslen=146) at crypto/evp/m_sigver.c:170
#14 0x00007fcadc9f4e96 in tls_construct_cert_verify (s=0x7fca80ee7ae0, pkt=0x7fca6f7dc6c0) at ssl/statem/statem_lib.c:307
#15 0x00007fcadc9e8511 in write_state_machine (s=0x7fca80ee7ae0) at ssl/statem/statem.c:843
#16 0x00007fcadc9e79bc in state_machine (s=0x7fca80ee7ae0, server=1) at ssl/statem/statem.c:443
#17 0x00007fcadc9e74a0 in ossl_statem_accept (s=0x7fca80ee7ae0) at ssl/statem/statem.c:255
#18 0x00007fcadc9afda8 in ssl3_read_bytes (s=0x7fca80ee7ae0, type=23, recvd_type=0x0, buf=0x7fca6f7dca00 "", len=4096, peek=0, readbytes=0x7fca6f7dc9e0) at ssl/record/rec_layer_s3.c:1278
#19 0x00007fcadc9bc563 in ssl3_read_internal (s=0x7fca80ee7ae0, buf=0x7fca6f7dca00, len=4096, peek=0, readbytes=0x7fca6f7dc9e0) at ssl/s3_lib.c:4464
#20 0x00007fcadc9bc63a in ssl3_read (s=0x7fca80ee7ae0, buf=0x7fca6f7dca00, len=4096, readbytes=0x7fca6f7dc9e0) at ssl/s3_lib.c:4488
#21 0x00007fcadc9ca99d in ssl_read_internal (s=0x7fca80ee7ae0, buf=0x7fca6f7dca00, num=4096, readbytes=0x7fca6f7dc9e0) at ssl/ssl_lib.c:1763
#22 0x00007fcadc9ca9fa in SSL_read (s=0x7fca80ee7ae0, buf=0x7fca6f7dca00, num=4096) at ssl/ssl_lib.c:1777
#23 0x00007fcade717470 in ssl_handler_read (socket=0x7fca1bca5bf8, current=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/ssl.c:197
#24 0x00007fcade70acb6 in handler_call_stack_param (socket=0x7fca1bca5bf8, aspect=<optimized out>, param=0x0) at /var/SVN/server-side/engine/branches/stable/c/cclib/handler.c:176
#25 0x00007fcade7101b7 in thread_worker_oper (e=<optimized out>, td=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:577
#26 0x00007fcade70f460 in thread_worker (thread=<optimized out>, data=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:774
#27 0x00007fcada81b0a4 in start_thread (arg=0x7fca6f7de700) at pthread_create.c:309
#28 0x00007fcada55087d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

I see this in 1.1.1k changelog:
     Fixed an issue where an OpenSSL TLS server may crash if sent a maliciously
     crafted renegotiation ClientHello message from a client. If a TLSv1.2
     renegotiation ClientHello omits the signature_algorithms extension (where
     it was present in the initial ClientHello), but includes a
     signature_algorithms_cert extension then a NULL pointer dereference will
     result, leading to a crash and a denial of service attack.

     A server is only vulnerable if it has TLSv1.2 and renegotiation enabled
     (which is the default configuration). OpenSSL TLS clients are not impacted
     by this issue.

It isn't my crash maybe?

Probably unrelated. Your stack trace is deep in the RSA implementation.

In 1.1.1l version there was such fix:
"Fixed an SM2 Decryption Buffer Overflow. (...) This can lead to a buffer overflow when EVP_PKEY_decrypt()"
It won't help for our crashes - they still happens - but maybe there is similar issue in EVP_PKEY_sign (or EVP_DigestSign) function? Maybe somebody can check this.
And there is next difference in stacktrace for crash in 1.1.1l (there is tls_construct_server_key_exchange instead of tls_construct_cert_verify):
 #0  0x00007f662cf0c067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1  0x00007f662cf0d448 in __GI_abort () at abort.c:89 #2  0x00007f6631183ffe in signal_core (signum=<optimized out>, si=<optimized out>, arg=0x6) at /var/SVN/server-side/engine/branches/stable/c/linux/signal.c:140 #3  <signal handler called> #4  bn_sqr8x_internal () at crypto/bn/x86_64-mont5.s:1762 #5  0x00007f662efa779b in bn_power5 () at crypto/bn/x86_64-mont5.s:1171 #6  0x00007f662ef8ec6d in BN_mod_exp_mont_consttime (rr=0x7f66054bfae8, a=0x7f66054bfae8, p=0x3a0e470, m=0x3a0e310, ctx=0x7f6604235dc0, in_mont=0x7f65e0022ae0) at crypto/bn/bn_exp.c:1007 #7  0x00007f662f0b3676 in rsa_ossl_mod_exp (r0=0x7f66054bfab8, I=0x7f66054bfaa0, rsa=0x3a0c0b0, ctx=0x7f6604235dc0) at crypto/rsa/rsa_ossl.c:677 #8  0x00007f662f0b2694 in rsa_ossl_private_encrypt (flen=256,      from=0x7f66042269d0 "\032ǺTFd\361\260;\177\005\364;\t&\375\271\256\200V\303T\201\312Ԡ%[\333\303\061\311\365(r\346\257\bٗ\204S\310\325]\272h\373g\336\270\360\226\253\242ڙ\222Z\b\212\226\227\305\332\334&\021\032\375\302x6lV\362}\350'7\252\254\257\032\031\b3˸\032E \244\005YA\344\312\306\356\064\354\213\004=\364\301lGЕ\245\"\301\003ܮ\266[\370\272#\003\373\220\305x\001\356t\"\345s\316\321\371&\036\b\273C\343~/\337xۆ$\337\336S7\335\032\304(x\256\250N\222\303\\\035!\273\264\006;\253I\t\255\217\205\215\070|\321\360~\312k\337\302̈\243b\311[\365\330\v\274\060", <incomplete sequence \355>...,
to=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, rsa=0x3a0c0b0, padding=3) at crypto/rsa/rsa_ossl.c:316
#9  0x00007f662f0ae26b in RSA_private_encrypt (flen=256,
from=0x7f66042269d0 "\032ǺTFd\361\260;\177\005\364;\t&\375\271\256\200V\303T\201\312Ԡ%[\333\303\061\311\365(r\346\257\bٗ\204S\310\325]\272h\373g\336\270\360\226\253\242ڙ\222Z\b\212\226\227\305\332\334&\021\032\375\302x6lV\362}\350'7\252\254\257\032\031\b3˸\032E \244\005YA\344\312\306\356\064\354\213\004=\364\301lGЕ\245"\301\003ܮ\266[\370\272#\003\373\220\305x\001\356t"\345s\316\321\371&\036\b\273C\343~/\337xۆ$\337\336S7\335\032\304(x\256\250N\222\303\\035!\273\264\006;\253I\t\255\217\205\215\070|\321\360~\312k\337\302̈\243b\311[\365\330\v\274\060", <incomplete sequence \355>...,      to=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, rsa=0x3a0c0b0, padding=3) at crypto/rsa/rsa_crpt.c:36 #10 0x00007f662f0b5192 in pkey_rsa_sign (ctx=0x7f66045a1ba0,      sig=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978, tbs=0x7f65c3fe58a0 "\032\314\363;\276L", tbslen=32) at crypto/rsa/rsa_pmeth.c:176 #11 0x00007f662f067671 in EVP_PKEY_sign (ctx=0x7f66045a1ba0,      sig=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978, tbs=0x7f65c3fe58a0 "\032\314\363;\276L", tbslen=32) at crypto/evp/pmeth_fn.c:66 #12 0x00007f662f063563 in EVP_DigestSignFinal (ctx=0x7f66045a1b10,      sigret=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978) at crypto/evp/m_sigver.c:148 #13 0x00007f662f063690 in EVP_DigestSign (ctx=0x7f66045a1b10,      sigret=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978,      tbs=0x7f6604000ad0 "\237\305\373\246L5WR\200,\365\002\357\310P~\273\024\347\315b7i\264\tG\345\257AC\351\344\334ۢ\200\233\376\374=\227\025f\325Ce\333\063.,\003\265#\361dXDOWNGRD\001\003", tbslen=133) at crypto/evp/m_sigver.c:170 #14 0x00007f662f46f684 in tls_construct_server_key_exchange (s=0x7f6618712d70, pkt=0x7f65c3fe5ab0) at ssl/statem/statem_srvr.c:2826 #15 0x00007f662f4589d2 in write_state_machine (s=0x7f6618712d70) at ssl/statem/statem.c:843 #16 0x00007f662f457e7d in state_machine (s=0x7f6618712d70, server=1) at ssl/statem/statem.c:443 #17 0x00007f662f457961 in ossl_statem_accept (s=0x7f6618712d70) at ssl/statem/statem.c:255 #18 0x00007f662f41fe24 in ssl3_read_bytes (s=0x7f6618712d70, type=23, recvd_type=0x0, buf=0x7f65c3fe5e00 "\206", len=4096, peek=0, readbytes=0x7f65c3fe5dd0) at ssl/record/rec_layer_s3.c:1278 #19 0x00007f662f42c5cd in ssl3_read_internal (s=0x7f6618712d70, buf=0x7f65c3fe5e00, len=4096, peek=0, readbytes=0x7f65c3fe5dd0) at ssl/s3_lib.c:4464 #20 0x00007f662f42c6a4 in ssl3_read (s=0x7f6618712d70, buf=0x7f65c3fe5e00, len=4096, readbytes=0x7f65c3fe5dd0) at ssl/s3_lib.c:4488 #21 0x00007f662f43aadb in ssl_read_internal (s=0x7f6618712d70, buf=0x7f65c3fe5e00, num=4096, readbytes=0x7f65c3fe5dd0) at ssl/ssl_lib.c:1769 #22 0x00007f662f43ab38 in SSL_read (s=0x7f6618712d70, buf=0x7f65c3fe5e00, num=4096) at ssl/ssl_lib.c:1783 #23 0x00007f6631187480 in ssl_handler_read (socket=0x7f6577be1660, current=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/ssl.c:209 #24 0x00007f663117ad36 in handler_call_stack_param (socket=0x7f6577be1660, aspect=<optimized out>, param=0x0) at /var/SVN/server-side/engine/branches/stable/c/cclib/handler.c:176 #25 0x00007f66311802c7 in thread_worker_oper (e=<optimized out>, td=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:577 #26 0x00007f663117f570 in thread_worker (thread=<optimized out>, data=<optimized out>) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:774 #27 0x00007f662d28a0a4 in start_thread (arg=0x7f65c3fe7700) at pthread_create.c:309 #28 0x00007f662cfbf87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The fixes where specific to the implementations of SM2 algorithm. The backtrace shows a crash in the (optimized) RSA algorithm code.
It is highly unlike that there is a problem in that part of the OpenSSL code.  Somewhere else a pointer is getting clobbered is much more likely.
From: gleszczynski @.>
Reply-To: openssl/openssl @.>
Date: Tuesday, November 16, 2021 at 5:26 AM
To: openssl/openssl @.>
Cc: Rich Salz @.>, Comment @.***>
Subject: Re: [openssl/openssl] Rare and random crash in bn_sqr8x_internal (#13723)
In 1.1.1l version there was such fix:
"Fixed an SM2 Decryption Buffer Overflow. (...) This can lead to a buffer overflow when EVP_PKEY_decrypt()"
It won't help for our crashes - they still happens - but maybe there is similar issue in EVP_PKEY_sign (or EVP_DigestSign) function? Maybe somebody can check this.
And there is next difference in stacktrace for crash in 1.1.1l (there is tls_construct_server_key_exchange instead of tls_construct_cert_verify):
#0 0x00007f662cf0c067 in __GI_raise @.***=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f662cf0d448 in __GI_abort () at abort.c:89 #2 0x00007f6631183ffe in signal_core (signum=, si=, arg=0x6) at /var/SVN/server-side/engine/branches/stable/c/linux/signal.c:140 #3  #4 bn_sqr8x_internal () at crypto/bn/x86_64-mont5.s:1762 #5 0x00007f662efa779b in bn_power5 () at crypto/bn/x86_64-mont5.s:1171 #6 0x00007f662ef8ec6d in BN_mod_exp_mont_consttime (rr=0x7f66054bfae8, a=0x7f66054bfae8, p=0x3a0e470, m=0x3a0e310, ctx=0x7f6604235dc0, in_mont=0x7f65e0022ae0) at crypto/bn/bn_exp.c:1007 #7 0x00007f662f0b3676 in rsa_ossl_mod_exp (r0=0x7f66054bfab8, I=0x7f66054bfaa0, rsa=0x3a0c0b0, ctx=0x7f6604235dc0) at crypto/rsa/rsa_ossl.c:677 #8 0x00007f662f0b2694 in rsa_ossl_private_encrypt (flen=256, from=0x7f66042269d0 "\032ǺTFd\361\260;\177\005\364;\t&\375\271\256\200V\303T\201\312Ԡ%[\333\303\061\311\365(r\346\257\bٗ\204S\310\325]\272h\373g\336\270\360\226\253\242ڙ\222Z\b\212\226\227\305\332\334&\021\032\375\302x6lV\362}\350'7\252\254\257\032\031\b3˸\032E \244\005YA\344\312\306\356\064\354\213\004=\364\301lGЕ\245"\301\003ܮ\266[\370\272#\003\373\220\305x\001\356t"\345s\316\321\371&\036\b\273C\343~/\337xۆ$\337\336S7\335\032\304(x\256\250N\222\303\\035!\273\264\006;\253I\t\255\217\205\215\070|\321\360~\312k\337\302̈\243b\311[\365\330\v\274\060", <incomplete sequence \355>...,
to=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, rsa=0x3a0c0b0, padding=3) at crypto/rsa/rsa_ossl.c:316
#9https://urldefense.com/v3/__https:/github.com/openssl/openssl/pull/9__;!!GjvTz_vk!HQtH4oVi21LJQlpebpO-ZHWwdgyqNFXaFYvdres1GV_S48WOWBe9YawnuLjL$ 0x00007f662f0ae26b in RSA_private_encrypt (flen=256,
from=0x7f66042269d0 "\032ǺTFd\361\260;\177\005\364;\t&\375\271\256\200V\303T\201\312Ԡ%[\333\303\061\311\365(r\346\257\bٗ\204S\310\325]\272h\373g\336\270\360\226\253\242ڙ\222Z\b\212\226\227\305\332\334&\021\032\375\302x6lV\362}\350'7\252\254\257\032\031\b3˸\032E \244\005YA\344\312\306\356\064\354\213\004=\364\301lGЕ\245"\301\003ܮ\266[\370\272#\003\373\220\305x\001\356t"\345s\316\321\371&\036\b\273C\343~/\337xۆ$\337\336S7\335\032\304(x\256\250N\222\303\035!\273\264\006;\253I\t\255\217\205\215\070|\321\360~\312k\337\302̈\243b\311[\365\330\v\274\060", <incomplete sequence \355>..., to=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, rsa=0x3a0c0b0, padding=3) at crypto/rsa/rsa_crpt.c:36 #10 0x00007f662f0b5192 in pkey_rsa_sign (ctx=0x7f66045a1ba0, sig=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978, tbs=0x7f65c3fe58a0 "\032\314\363;\276L", tbslen=32) at crypto/rsa/rsa_pmeth.c:176 #11 0x00007f662f067671 in EVP_PKEY_sign (ctx=0x7f66045a1ba0, sig=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978, tbs=0x7f65c3fe58a0 "\032\314\363;\276L", tbslen=32) at crypto/evp/pmeth_fn.c:66 #12 0x00007f662f063563 in EVP_DigestSignFinal (ctx=0x7f66045a1b10, sigret=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978) at crypto/evp/m_sigver.c:148 #13 0x00007f662f063690 in EVP_DigestSign (ctx=0x7f66045a1b10, sigret=0x7f6605a6b94d "co Data Systems S.A.1<0:\006\003U\004\003\f3Certum Domain Validation CA SHA2 Validation Service\030\017\062\060\062\061\061\061\061\063\060\067\062\060\062\061Z0q0o0G0\a\006\005+\016\003\002\032\004\024\315p#\343'\217}\224y\237=Kϱ\030\363\257V\034\207\004\024\345\061\255\277:\021\226\364\203\274P<Է\220\233\220\356\336%\002\020\064\331S\237pP\244\253\330\027\234\364\253", <incomplete sequence \374\200>, siglen=0x7f65c3fe5978, tbs=0x7f6604000ad0 "\237\305\373\246L5WR\200,\365\002\357\310P~\273\024\347\315b7i\264\tG\345\257AC\351\344\334ۢ\200\233\376\374=\227\025f\325Ce\333\063.,\003\265#\361dXDOWNGRD\001\003", tbslen=133) at crypto/evp/m_sigver.c:170 #14 0x00007f662f46f684 in tls_construct_server_key_exchange (s=0x7f6618712d70, pkt=0x7f65c3fe5ab0) at ssl/statem/statem_srvr.c:2826 #15 0x00007f662f4589d2 in write_state_machine (s=0x7f6618712d70) at ssl/statem/statem.c:843 #16 0x00007f662f457e7d in state_machine (s=0x7f6618712d70, server=1) at ssl/statem/statem.c:443 #17 0x00007f662f457961 in ossl_statem_accept (s=0x7f6618712d70) at ssl/statem/statem.c:255 #18 0x00007f662f41fe24 in ssl3_read_bytes (s=0x7f6618712d70, type=23, recvd_type=0x0, buf=0x7f65c3fe5e00 "\206", len=4096, peek=0, readbytes=0x7f65c3fe5dd0) at ssl/record/rec_layer_s3.c:1278 #19 0x00007f662f42c5cd in ssl3_read_internal (s=0x7f6618712d70, buf=0x7f65c3fe5e00, len=4096, peek=0, readbytes=0x7f65c3fe5dd0) at ssl/s3_lib.c:4464 #20 0x00007f662f42c6a4 in ssl3_read (s=0x7f6618712d70, buf=0x7f65c3fe5e00, len=4096, readbytes=0x7f65c3fe5dd0) at ssl/s3_lib.c:4488 #21 0x00007f662f43aadb in ssl_read_internal (s=0x7f6618712d70, buf=0x7f65c3fe5e00, num=4096, readbytes=0x7f65c3fe5dd0) at ssl/ssl_lib.c:1769 #22 0x00007f662f43ab38 in SSL_read (s=0x7f6618712d70, buf=0x7f65c3fe5e00, num=4096) at ssl/ssl_lib.c:1783 #23 0x00007f6631187480 in ssl_handler_read (socket=0x7f6577be1660, current=) at /var/SVN/server-side/engine/branches/stable/c/cclib/ssl.c:209 #24 0x00007f663117ad36 in handler_call_stack_param (socket=0x7f6577be1660, aspect=, param=0x0) at /var/SVN/server-side/engine/branches/stable/c/cclib/handler.c:176 #25 0x00007f66311802c7 in thread_worker_oper (e=, td=) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:577 #26 0x00007f663117f570 in thread_worker (thread=, data=) at /var/SVN/server-side/engine/branches/stable/c/cclib/thread.c:774 #27 0x00007f662d28a0a4 in start_thread (arg=0x7f65c3fe7700) at pthread_create.c:309 #28 0x00007f662cfbf87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/openssl/openssl/issues/13723*issuecomment-970130365__;Iw!!GjvTz_vk!HQtH4oVi21LJQlpebpO-ZHWwdgyqNFXaFYvdres1GV_S48WOWBe9YV6dvBG4$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABX6FFFEPDPMJEQFANX2UNLUMIWTTANCNFSM4VEKF5KA__;!!GjvTz_vk!HQtH4oVi21LJQlpebpO-ZHWwdgyqNFXaFYvdres1GV_S48WOWBe9YbOPbiMx$.
Triage notifications on the go with GitHub Mobile for iOShttps://urldefense.com/v3/__https:/apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!GjvTz_vk!HQtH4oVi21LJQlpebpO-ZHWwdgyqNFXaFYvdres1GV_S48WOWBe9YVpehYNN$ or Androidhttps://urldefense.com/v3/__https:/play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!GjvTz_vk!HQtH4oVi21LJQlpebpO-ZHWwdgyqNFXaFYvdres1GV_S48WOWBe9YeOUEm2x$.


[rancher-compose] up --upgrade re-create containers even there is no change to the service definition in docker-compose.yml

Rancher Version:
Server v1.1.1, rancher-compose v0.8.6
Docker Version:
1.11.1
OS and where are the hosts located? (cloud, bare metal, etc):
AWS EC2, Amazon Linux
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single server node with external MySQL DB on RDS
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Simply create a service and deploy it twice with up --upgrade and the 2nd Rancher still stops the running container and starts a new one.
Results:
Service container(s) is recreated even there is no change to the docker-compose.yml.
Expected:
Service containers(s) should remain untouched.
I am pretty sure it worked in some old version (v1.0.0?), as in my real example, we defined two services in docker-compose.yml, one is the app itself, and the other one is the load balancer, and only the app containers were recreated and load-balancer containers were untouched. But now it recreate all containers in docker-compose.yml, no matter it is changed or not.

Turned out to be some auto-generated labels on the service changes every time the service is deployed.


tensorflow 2.0,and training model,does it work?

I'm a unity developer,wanna use tensorflow.
so i found this.and wanna use tensorflow 2.0 for unity
i wonder if it works with tensorflow 2.0 model training.
I see you upgrade your project last month.
so i wonder if you can support tensorflow 2.0

@HolyShitKillingMachine,
Unfortunately no, I don't think it's possible since TensorflowSharp plugin only supports earlier versions of TensorFlow. Unless tf2 has some kind of backward compatibility model freezing or converting which I don't think it does. Unity won't be updating the plugin since they have their own inference engine now.
So another option would be to train with TensorFlow 2, freeze the model and try to convert it to Barracuda format to use with Unity's new Barracuda inference engine. See my other example: https://github.com/Syn-McJ/TFClassify-Unity-Barracuda

@HolyShitKillingMachine,
Unfortunately no, I don't think it's possible since TensorflowSharp plugin only supports earlier versions of TensorFlow. Unless tf2 has some kind of backward compatibility model freezing or converting which I don't think it does. Unity won't be updating the plugin since they have their own inference engine now.
So another option would be to train with TensorFlow 2, freeze the model and try to convert it to Barracuda format to use with Unity's new Barracuda inference engine. See my other example: https://github.com/Syn-McJ/TFClassify-Unity-Barracuda

So ,it is too difficult for the fresh tensorflow user to use the object-detection

@HolyShitKillingMachine
It's not that difficult, but if you a new user it might be a challenge, yes.

@Syn-McJ I am using the project ,and using 1.7.1 tensorflow ,export my pb file,change to bytes.use the classify,but came with the error in windows,

After exporting it to a apk,it does not work

@Syn-McJ
the png has failed to upload
Error is this!
TFException: Invalid GraphDef
TensorFlow.TFStatus.CheckMaybeRaise (TensorFlow.TFStatus incomingStatus, System.Boolean last) (at <1fe2de69842a4a4ba15256b83cca05f3>:0)
TensorFlow.TFGraph.Import (TensorFlow.TFBuffer graphDef, TensorFlow.TFImportGraphDefOptions options, TensorFlow.TFStatus status) (at <1fe2de69842a4a4ba15256b83cca05f3>:0)
TensorFlow.TFGraph.Import (System.Byte[] buffer, TensorFlow.TFImportGraphDefOptions options, TensorFlow.TFStatus status) (at <1fe2de69842a4a4ba15256b83cca05f3>:0)
TensorFlow.TFGraph.Import (System.Byte[] buffer, System.String prefix, TensorFlow.TFStatus status) (at <1fe2de69842a4a4ba15256b83cca05f3>:0)
TFClassify.Classifier..ctor (System.Byte[] model, System.String[] labels, System.Int32 inputSize) (at Assets/Scripts/Classifier.cs:31)
PhoneCamera.LoadClassifier () (at Assets/Scripts/PhoneCamera.cs:170)
PhoneCamera.LoadWorker () (at Assets/Scripts/PhoneCamera.cs:163)
PhoneCamera.Start () (at Assets/Scripts/PhoneCamera.cs:59)

i have checked that ,ML Agent seems not to work with 1.7.1
https://github.com/Unity-Technologies/ml-agents/issues/609

@HolyShitKillingMachine
If you trained your model with tf 1.7.1, you will need to install 0.4 version of the plugin:
https://s3.amazonaws.com/unity-ml-agents/0.4/TFSharpPlugin.unitypackage

@Syn-McJ i have tested it with 0.4 version tf1.7.1,and it works bad.
came out this problem.
shows the Invalid GraphDef problem

@HolyShitKillingMachine
If you send me your model, I can take a look at it and check why it doesn't work.

@Syn-McJ OK，i hava change the pb to bytes,and it can recognize apple and banana!

it is too big for upload!
can you give me your email,so that i can send to you @Syn-McJ

@Syn-McJ Now,i am using the Barracuda sample,hope it works.
I am using a android projector,and wanna detect  and show the recipe about the food,and the projecter is used in smart home.

@HolyShitKillingMachine,
SSD model won't work with barracuda, you'll need a YOLO model for that.
You can send me your model on<EMAIL_ADDRESS>

could i use tensorflow1.14.0 to train my model to use in this project ? thank U

@tomret,
No, you can use tf 1.4 with the 0.3 version of plugin or 1.7.1 with the 0.4 version of the plugin.
If you need to use other tensorflow versions, you might try to convert your model to Barracuda format and try my other example: https://github.com/Syn-McJ/TFClassify-Unity-Barracuda

@HolyShitKillingMachine
Your model seems to be fine, you're using the wrong scene. Classify is for image classification, Detect is for object detection.


BatchableDB

What was wrong?
There was no way to use LevelDB's built-in write batching.
How was it fixed?

Added a new BaseBatchableDB which extends the BaseDB API, for write batching
Added a new BatchableDB as a parallel to MemoryDB that supports batching. (Note that it's different from BatchDB, which always batches requests until commit. BatchableDB will immediately commit any changes outside of a batch_write context.)
Added support for batch_write to the LevelDB backend

This is not yet wired up to anything, it's a few starting commits PR stripped off of #1279
Cute Animal Picture

Naming wise, this might be better called AtomicDB which helps differentiate it from BatchDB, and the context method could be with atomicdb.atomic_batch() which I think communicates what is happening a little clearer.


Most templates fail to start / build out of the box

So after spending quite a few hours, I decided to test every template instead of giving up.
I used the following environment. The template firebase-auth even failed to create. I've uploaded an 11mb archive to https://www.binaryturf.com/wp-content/uploads/2018/09/react-static-template-test.tar.bz2 with all the template code,
Each folder has two files start.log and build.log inside each template folder (minus the node_modules else it was reaching about 3GB).
Additionally the top directory has test report and the environment details (mentioning the same here in as well)
Apologize if I made any stupid errors during testing. All templates were out of the box except for the addition of siteRoot var in static.config.js. I'm happy to test more on request. I'm not going to try some on a vanilla debian vm to see if there's something I can use.
The following was the environment:
node: v10.11.0
yarn: 1.10.1
{ npm: '6.4.1',
  ares: '1.14.0',
  cldr: '33.1',
  http_parser: '2.8.0',
  icu: '62.1',
  modules: '64',
  napi: '3',
  nghttp2: '1.33.0',
  node: '10.11.0',
  openssl: '1.1.0i',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.23.0',
  v8: '6.8.275.32-node.28',
  zlib: '1.2.11' }
macOS High Sierra 10.13.3 (17D102)```

Almost all of the errors I'm seeing in these logs are babel related. It appears either a babel plugin is missing entirely, or one of them is misbehaving on your machine.
If you remove the siteRoot modification, do any more of them build?

This certainly needs some verification. I wouldn't have gone through the pain of all this testing if it worked on wither of my Win 10, Mac High Sierra, Ubuntu WSL or Arch OSes.


Add channel age restriction commentron in creator settings

Since we only started tracking on Monday, the oldest you can go back is then. Can do minutes, hours, or days. A UI note about Feb 7 will do. Will get info about the API soon.

Arguement to settings update is: TimeSinceFirstComment
It's in minutes.
From UI, generally, people will do minutes, hours or days.
Max date it can do is back to : 2022-02-08 - so don't allow a days value that's higher than this. (hint before selection / submission if possible)


CI takes 8 hours to complete

Because of the growing number of dependencies from near-sdk and the number of examples, the single CI run now takes 1 hour.
We run 8 jobs:

nearcore master/nearcore crates
local branch/local PR
stable/nightly

This blocks other users of Travis in near and too slow.

Also note, that we recompile every example and test every example. This takes time, because there is no cache.

Also note, that we recompile every example and test every example. This takes time, because there is no cache.


README.md: Changes the layout to match HQRM resources

Changes to README.md

Change the layout of the README.md to closer match the one of PSDscResources
Added more detailed text explaining what operating systemes WMF5.0 can be installed on.
Fixed alphabetical order, one resource was not in the right order.
Verified all resource schema files with the README.md and fixed any errors.

This Pull Request (PR) fixes the following issues:
Fixes #221

[x] Change details added to Unreleased section of CHANGELOG.md?
[ ] Added/updated documentation, comment-based help and descriptions in .schema.mof files where appropriate?
[ ] Examples appropriately updated?
[x] New/changed code adheres to Style Guidelines?
[ ] Unit and (optional) Integration tests created/updated where possible?

This change is

If anyone feels like reviewing, then feel free to review this one. 😄

Reviewed 1 of 2 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


[WFCORE-3638] Coverity, dead code in AbstractEnableSSLCommand and Key…

…StoresTestCase
https://issues.jboss.org/browse/WFCORE-3638

@jfdenise , @fjuma could you review? You are authors of removed code. So if by chance it is not intentional.

Core - Full Integration Build 6884 outcome was FAILURE using a merge of ac0a67d2bb205e39baa3936c0c06915751c14e69
Summary: Tests failed: 3 (3 new), passed: 4285, ignored: 143 Build time: 01:33:07
Failed tests
org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.testReverseProxy: java.lang.AssertionError: expected:<200> but was:<404>
	at org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.performCall(ReverseProxyTestCase.java:202)
	at org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.testReverseProxy(ReverseProxyTestCase.java:212)
------- Stdout: -------
 [0m09:54:27,797 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 6) WFLYUT0022: Unregistered web context: '/multipathTest' from server 'default-server'
 [0m [0m09:54:27,801 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment multipathTest.war (runtime-name: multipathTest.war) in 4ms
 [0m [0m09:54:27,805 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/4d/17de4f904a55f45b1de614061eb15876a40df9/content
 [0m [0m09:54:27,805 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "multipathTest.war" (runtime-name: "multipathTest.war")
 [0m [0m09:54:27,816 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/d6/0404487135e29a974c22f789c4d826c121044b/content
 [0m [0m09:54:27,817 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "server2.war" (runtime-name: "server2.war")
 [0m [0m09:54:27,855 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 6) WFLYUT0021: Registered web context: '/server2' for server 'default-server'
 [0m [0m09:54:27,859 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "server2.war" (runtime-name : "server2.war")
 [0m [0m09:54:27,869 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/ea/bc29bf7f2014884ce1bd7454e92bab820fd1df/content
 [0m [0m09:54:27,871 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "server1.war" (runtime-name: "server1.war")
 [0m [0m09:54:27,915 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 6) WFLYUT0021: Registered web context: '/server1' for server 'default-server'
 [0m [0m09:54:27,919 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "server1.war" (runtime-name : "server1.war")
 [0m

org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase: 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:184)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:162)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:91)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:244)
------- Stdout: -------
 [0m09:54:28,154 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/0b/518bd5de6bb8f548cf8ab1f682520737d2e1c3/content
 [0m [0m09:54:28,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "root-web.ear" (runtime-name: "root-web.ear")
 [0m [0m09:54:28,164 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0207: Starting subdeployment (runtime-name: "root-web.war")
 [0m [31m09:54:28,199 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "root-web.ear")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [31m09:54:28,200 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "root-web.ear" was rolled back with the following failure message:
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [0m09:54:28,206 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: root-web.war) in 5ms
 [0m [0m09:54:28,207 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment root-web.ear (runtime-name: root-web.ear) in 7ms
 [0m

org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase: 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:184)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:162)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:91)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:244)
------- Stdout: -------
 [0m09:54:28,040 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 27) WFLYUT0022: Unregistered web context: '/server2' from server 'default-server'
 [0m [0m09:54:28,048 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment server2.war (runtime-name: server2.war) in 8ms
 [0m [0m09:54:28,053 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/d6/0404487135e29a974c22f789c4d826c121044b/content
 [0m [0m09:54:28,053 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "server2.war" (runtime-name: "server2.war")
 [0m [0m09:54:28,057 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 27) WFLYUT0022: Unregistered web context: '/server1' from server 'default-server'
 [0m [0m09:54:28,060 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment server1.war (runtime-name: server1.war) in 4ms
 [0m [0m09:54:28,063 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/ea/bc29bf7f2014884ce1bd7454e92bab820fd1df/content
 [0m [0m09:54:28,064 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "server1.war" (runtime-name: "server1.war")
 [0m [0m09:54:28,076 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/af/6bd2101f52f63dc831a7005cdbd814981abc53/content
 [0m [0m09:54:28,077 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "root-context.war" (runtime-name: "root-context.war")
 [0m [31m09:54:28,113 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "root-context.war")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [31m09:54:28,115 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "root-context.war" was rolled back with the following failure message:
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [0m09:54:28,122 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment root-context.war (runtime-name: root-context.war) in 7ms
 [0m

Core - Full Integration Build 6885 outcome was FAILURE using a merge of ac0a67d2bb205e39baa3936c0c06915751c14e69
Summary: Tests failed: 3, passed: 4285, ignored: 143 Build time: 01:35:34
Failed tests
org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.testReverseProxy: java.lang.AssertionError: expected:<200> but was:<404>
	at org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.performCall(ReverseProxyTestCase.java:202)
	at org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase.testReverseProxy(ReverseProxyTestCase.java:212)
------- Stdout: -------
 [0m10:04:26,730 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/multipathTest' from server 'default-server'
 [0m [0m10:04:26,737 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment multipathTest.war (runtime-name: multipathTest.war) in 6ms
 [0m [0m10:04:26,742 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/e8/3ef69893c49040910f9a2426dc567c52b2e4c3/content
 [0m [0m10:04:26,742 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "multipathTest.war" (runtime-name: "multipathTest.war")
 [0m [0m10:04:26,752 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/c7/41cac41846c452886d27eb3543c86b68aa6de8/content
 [0m [0m10:04:26,753 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "server1.war" (runtime-name: "server1.war")
 [0m [0m10:04:26,798 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 2) WFLYUT0021: Registered web context: '/server1' for server 'default-server'
 [0m [0m10:04:26,804 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "server1.war" (runtime-name : "server1.war")
 [0m [0m10:04:26,814 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/3e/363992039f5ace9f92fab86c1bbe1095234c88/content
 [0m [0m10:04:26,817 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "server2.war" (runtime-name: "server2.war")
 [0m [0m10:04:26,874 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 4) WFLYUT0021: Registered web context: '/server2' for server 'default-server'
 [0m [0m10:04:26,879 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "server2.war" (runtime-name : "server2.war")
 [0m

org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase: 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:184)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:162)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:91)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:244)
------- Stdout: -------
 [0m10:04:27,077 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/6a/2b18f1e607fc93fadf836d5016a047b9c93130/content
 [0m [0m10:04:27,080 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "root-web.ear" (runtime-name: "root-web.ear")
 [0m [0m10:04:27,091 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0207: Starting subdeployment (runtime-name: "root-web.war")
 [0m [31m10:04:27,135 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "root-web.ear")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [31m10:04:27,136 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "root-web.ear" was rolled back with the following failure message:
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [0m10:04:27,143 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: root-web.war) in 7ms
 [0m [0m10:04:27,144 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment root-web.ear (runtime-name: root-web.ear) in 8ms
 [0m

org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase: 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:184)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:162)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:91)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:244)
------- Stdout: -------
 [0m10:04:26,970 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 8) WFLYUT0022: Unregistered web context: '/server1' from server 'default-server'
 [0m [0m10:04:26,979 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment server1.war (runtime-name: server1.war) in 9ms
 [0m [0m10:04:26,983 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/c7/41cac41846c452886d27eb3543c86b68aa6de8/content
 [0m [0m10:04:26,983 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "server1.war" (runtime-name: "server1.war")
 [0m [0m10:04:26,987 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 4) WFLYUT0022: Unregistered web context: '/server2' from server 'default-server'
 [0m [0m10:04:26,990 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment server2.war (runtime-name: server2.war) in 4ms
 [0m [0m10:04:26,994 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/3e/363992039f5ace9f92fab86c1bbe1095234c88/content
 [0m [0m10:04:26,994 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "server2.war" (runtime-name: "server2.war")
 [0m [0m10:04:27,006 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /store/work/tc-work/29472398f1ae6497/full/testsuite/integration/web/target/wildfly/standalone/data/content/12/da3b0b938b05f7f89e0cbdef57110be375e87d/content
 [0m [0m10:04:27,007 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "root-context.war" (runtime-name: "root-context.war")
 [0m [31m10:04:27,045 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "root-context.war")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [31m10:04:27,045 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "root-context.war" was rolled back with the following failure message:
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.server.default-server.context-host"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.undertow.deployment.default-server.context-host./.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.context-host]",
        "jboss.undertow.deployment.default-server.context-host./ is missing [jboss.undertow.server.default-server.context-host]"
    ]
}
 [0m [0m10:04:27,049 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment root-context.war (runtime-name: root-context.war) in 4ms
 [0m

retest this please

Core - Full Integration Build 6920 outcome was FAILURE using a merge of ac0a67d2bb205e39baa3936c0c06915751c14e69
Summary: Execution timeout (new); tests passed: 4178, ignored: 141 Build time: 02:30:47

Core - Full Integration Build 6930 outcome was FAILURE using a merge of ac0a67d2bb205e39baa3936c0c06915751c14e69
Summary: Execution timeout; tests passed: 3821, ignored: 138 Build time: 02:30:18

retest this please


TypeError: browser.process is not a function

I want get the running browser's pid. In the document, i find the function "browser.process()".
in my test.js
new Promise(async () => { 	const puppeteer = require('puppeteer'); 	const browser = await puppeteer.launch({args: ['--no-sandbox',     '--disable-setuid-sandbox']}); 	console.log(browser.process()); 	process.exit(); });
but, when i try to run it, i find  a error: UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: browser.process is not a function
ps: I have run it on win and linux and return the same error message.
Am i use it wrong? Or is it just a bug?? please tell me....  Thank you very much

Make sure your version of the puppeteer and the version in the mentioned doc is the same.

browser.process was introduces in v1.0.0.


Metrics global intervals

Looks like there's some timing issues in the new tests, travis seems to be failing with a fairly high probability.

So it looks like there's a pretty big component this doesn't do yet, which might actually be ok until I get my branch merged in, but we need the event collectors that track multiple intervals (rate, PeriodicHistogram) to initialize with the global intervals instead of user-supplied ones, and then when the Ticks come in, they only report the metrics for the correct interval.  Right now A Periodic Histogram is going to end up reporting both its 1 second and 60 second aggregation in all intervals, so we're just duplicating our data.
Also in those cases the event collectors are only expecting one global tick, not one tick per interval, so I think its going to require some fairly significant changes to those classes.


Report security-affected php versions?

From what I can see, the repository contains no information about security advisories for PHP versions or PHP extensions.
While I know the ecosystem is hugely messed up here (because of linux LTS distros that just "invent" a new versioning system for backported security patches), it would still be a good idea to just report any PHP release that does reference a CVE.
I think this would hugely improve the push for deploying latest stable releases.
Thoughts?

not sure whether this fits into the scope of this repository. This one is mostly about checking your existing composer.json/lock against security issues, not the server env.

From a userland perspective I think expanding the scope to the PHP-runtime and extensions would be beneficial and provide visibility into the importance of security issues.

I think it is a great idea. Especially if you see the statistic from this Blog Posts https://developerjack.com/blog/2015/12/09/php-version-roundup/

the issue is that the checker tool takes a composer.lock as input currently.
Checking security issues in PHP and extensions would require a separate tooling (sending info about the PHP version and extensions instead). So it probably belongs to a separate repository (which may still be hosted in this organization though), with a separate checker backend.
Unless @fabpot wants to extend the scope of https://security.sensiolabs.org/ of course

I'm 👍 for adding information about PHP security issues. But keep in mind that the SensioLabs security checker is a tool used in dev/staging/testing envs, so, probably not the right tool to warn you about PHP issues.
Anyway, having everything centralized seems like a good idea. Then, tools can read and consume this information as they see fit.

The problem is always the same one: what about ancient dinosaurs like Debian Oldstable and RedHat enterprise pain? They don't expose composer-friendly PHP versions with fixes, sadly.

While I appreciate the effort, I don't think it's worth it. There are too many Linux distros with their own versions and PHP itself has good enough announcements for new security updates.
I asked on the Ubuntu packaging channel before, why they release their own versions instead of following upstream, and the only response was, that upstream does probably suck and break things in bugfix releases.
While PHP does have had breaking changes in minor versions, I think the risk of breaking changes in patch versions is rather low and compared to the security benefit, it's totally worth following upstream for patch releases. Would be cool if we could encourage distros to follow our patch releases at least.

There are already different security databases out there which track that. For example the Debian security-tracker. The problem with them is that they are platform dependent. Having a new datasource which only takes tags/versions from upsource into account is an idea I like a lot! I would love to integrate that into VersionEye.
The main input for VersionEye is the composer.json/composer.lock file. To make that Git & CI Integration work we would have to rely on meta information in the composer.json file. There could be a plugin which is reading meta information about the current PHP runtime and updating that information in the composer.json. Or it could be tracked in a separate file. In Ruby projects we have for example a .ruby-version file.

Maybe we could start by looking at every well-known linux distro and gather here the list of urls which can be used for each to ascertain all the vulns in all the versions of php they released over time and the subsequent patches? We could maybe also ask Jordi if he ask OS/php stats gathered by Composer, to get a feeling of which coverage percentage we would be reaching in term of OS...

Closing this issue as after thinking again about this, I think it's something related but at the same time very different.


[typespec - Verify PR] ERROR: File does not exist: /mnt/vss/_work/1/s/common/temp/rush-recycler

https://dev.azure.com/azure-sdk/public/_build/results?buildId=2880544&view=logs&j=2e5d64b2-130f-5138-828e-233e9a02d825&t=20846762-c033-5f10-b2f9-01db8dd0acb5&l=84
ERROR: File does not exist: /mnt/vss/_work/1/s/common/temp/rush-recycler
ENOENT: no such file or directory, scandir
'/mnt/vss/_work/1/s/common/temp/rush-recycler'
##[error]Bash exited with code '1'.

not applicable anymore as we don't use rush


Add blocking framework on-top of Occurrent

Can be called "Bloccurrent" or "Blockurrent" :)

Borrow ideas from Fiffi


Fix #1441 add icon files notice

Please answer these questions before submitting pull request

Why submit this pull request?

[x] Bug fix

[ ] New feature provided

[ ] Improve performance

Related issues

Fix #1441

We should not add the ASF License header to the iconfont.svg if the file is just copied from dant.

Yes. @WillemJiang already removed it at UI repository and submodule updated.


3d maps load order is glitchy

Its common to get large white areas randomly in the middle, while very distant tiles loaded straight away:

Sometimes these white gaps linger for ages. This is from the 3d maps example in the docs.

Another from the docs. Here a few non-contiguous patches of point cloud loaded


Clarify sleep icon

There is a "zzz" in the swaybar, which says "deactivated" on hover and "activated" once clicked.
I am guessing that I can disable automatic sleep with it, but it would be good to clarify.

It's not about sleeping, but the tools that sets idle (screen light, lock screen).

oh, so it is a "screen always on" function? Well I rarely care about that, I'd much prefer the option to enable and disable auto-sleep, as screen lock won't disturb any running processes either way.


🔖 Release v0.0.9

This is a small patch release to fix a critical regression that broke v1.2 OPDS:
Fixes https://github.com/stumpapp/stump/issues/513
Fixes https://github.com/stumpapp/stump/issues/516

I'll wait for the nightly image to finish, then I will re-validate the fixes in this diff. At that point, I'll kick off the versioned release process to get the fixes out

Everything OPDS-related seems to be a-okay at a glance, so I'll merge this in


Adding color clues to the human figure.

Figured out how to do it! Love the Port/Starboard colored shoes.
The Slicer people are really clever.

Wow!


Add unit tests for RequestBuilder in turms-client-swift

For better maintainability, we remove the flexible RequestBuilder which uses a JSON string to construct a TurmsRequest.


SyncBot, ProcBots: Could contain a command (line) infrastructure

SyncBot, and possibly the ProcBots framework, could support a set of commands that pertain to the process itself.  Things like info and kill, protected by a secret in the env vars.

Would @hedss be able to kick VersionBot? :joy:

The way I envisage this working is the the ProcBot class includes a command parser method, which when receiving commands will, like Zhu Li, 'do the thing'.
This can then be hooked in if required by an inheriting child bot by calling the method as part of an event registration.
For example, imagine that we want to be able to use this in Github. We most definitely don't want general access on public repositories, as any reported information could potentially be used as a security breach. So maybe we ask VersionBot/SyncBot/WotBot to only honour the parser in private repositories. We can go further than this too, we can setup a whitelist so that only specific users are allowed to use the parser. And we can go even further than this, perhaps ensuring that only comments in a PR can trigger it.
Take then, the checkFooterTags in VersionBot, which receives an event.
protected checkFooterTags = (_registration: GithubRegistration, event: ServiceEvent): Promise<void> => {
    ...
    return this.dispatchToEmitter(this.githubEmitterName, {
        data: {
        owner,
	repo: name,
	number: pr.number,
    },
    method: this.githubApi.issues.getComments
    }).then((comments: GithubApiTypes.Comment[]) => {
        _.each(comments, (comment) => {
            if ((comment.body === 'status') &&
                _.find(['hedss', 'sqweelygig', 'brownjohnf'], (user) => { comment.user === user })) {
                    this.parseCommand(comment.body);
            }
        });
    }).then(...
    );
}

We could have a configurable whitelist, etc. etc, but you get the idea.


feat: Unicode tables generation tool

Tool to generate Unicode property tables using the skip list data structure. The skip list, which is the data structure used in Rust, allows to create tables with very small memory footprint. The code generator is currently specialized for the numeric table, which we used as a first use case, but the skip list is general. The table search could be faster, but we leave this for future work. There is also a program to verify the table that we could use in the CI.

Thanks to the feedback, I'm wondering if I should either use a less memory efficient but less "ad hoc" data structure like a unicode trie or perhaps use a representation with pointers and without a contiguous offset array. Going back to the drawing board for now (WIP).


Create Wrapper Script for Installing Typings

Issue #1140
Bug
If a single package in the current project does not have a typings file, we fail to install any typings. This results in a poor IntelliSense experience.
Fix
Create a node script that wraps typings-core. This script will continue installation of all packages, even if some packages do not have typings files.
Testing
Tested on Node 6 so far with a few different scenarios, including projects where the typings for an installed package do not exist. Still have to test on earlier versions of node.
Closes #1140

Did a basic test pass with Node 0.12. My main concern was whether local module installs would behave, but it seems to work just fine.

:+1:


Parameter with default value no longer requested on deployment

Bicep version
Bicep BLI version 0.13.1 (e3ac80d678)
Describe the bug
in my bicep file:
param myParameter string = 'default value'
deploy with:
az deployment sub create --location uksouth --template-file  --parameters
if the parameter has a default value then the deployment does not ask me for a value for it anymore
if the parameter does not have a default value then the deployment asks me for a value
To Reproduce
Steps to reproduce the behaviour:

create a bicep file with a string parameter that has a default
deploy the file
notice that the parameter is not asked for
comment out the default value
deploy the file with the same command again
the parameter is asked for.

Additional context
I am fairly sure this used to work

I believe that is always how this has worked. Az CLI will not ask you for values if the code has a default, by design.


Fixed for Safari on OSX

Also added redirect to video if no AudioContext available
May fix #1, can't test due to lack of iOS device.

@prplz important fix please pull


Add Nerds & Company

Adding Nerds & Company to the list

[x] Company name
[x] Company description
[x] Company location
[x] GitHub link
[ ] How Elixir is used
[x] Sorted alphabetically

💥  Awesome addition, thank you @donpinkster! 👍


Fix REMOTETAGS

Handle REMOTETAGS the same way for all remote commands.
This fixes issues where remote commands are not building correctly on rhel7 and centos7 systems.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

LGTM assuming happy tests

Manually setting hold and LGTM

/hold cancel


Response is the same even after response file is modified

Not sure if it should re-read the file on every request by default or maybe make it an option in the config file

Implemented this, It's an option in the configuration file called loadOnce


Combine deploy based commands into a single command

This PR combines the following deploy based commands:
mevn create:git-repo
mevn dockerize
mevn deploy
The combined command is mevn deploy
On execution of this command, the CLI will prompt the user to select a deployment mode (GitHub/Heroku/Docker)

Replacing this PR with another one.


circExplorer calls fewer - strand circRNAs

Why? Fix it.

back_spliced.bed file generated by CircExplorer2 parse only has + strand... strand needs to be interpreted (and fixed) from junctions file ... writing script to do this

script _run_circExplorer_star.sh works.... but it needs junction file to correct for strand information in the BSJ file. ... for bwa the junction is empty ... so it doesn't work as intended.

Tried the following to use CIRI BAM to create a junctions file:

portcullis
regtools junctions extract
BAM-to-Junction-BED
... NONE of these worked... so abandoning this for now.


How can I implement a custom LLM model LangChain class wrapper for GPT4All model?

Is it possible to do what described here
https://gpt-index.readthedocs.io/en/latest/how_to/customization/custom_llms.html#example-using-a-custom-llm-model
or here
https://python.langchain.com/en/latest/modules/models/llms/examples/custom_llm.html#how-to-write-a-custom-llm-wrapper
whith  https://github.com/nomic-ai/gpt4all model?
I'd appreciate any help / hints!

Looks like it's implemented now: Langchain GPT4All integration


googlefonts: newlines in message

Description
This pull request adds newline to the message of com.google.fonts/check/integer_ppem_if_hinted
Before the change the message was:

This can be accomplished by using the 'gftools fix-hinting' command.
create virtualenvpython3 -m venv venv
activate virtualenvsource venv/bin/activate
install gftoolspip install git+https://www.github.com/googlefonts/tools

After the change the message is:

This can be accomplished by using the 'gftools fix-hinting' command.
create virtualenv
python3 -m venv venv
activate virtualenv
source venv/bin/activate
install gftools
pip install git+https://www.github.com/googlefonts/tools

To Do

[x] update CHANGELOG.md
[x] all checks to pass
[x] request a review

I will reopen this. It was closed by mistake

I will reopen this. It was closed by mistake


Dark Mode/ Flash

There's a flash on page load when user has dark mode set
We can inline the css and js to set up the page before it's rendered to the browser
Slowed down w/ connection throttling :

related https://github.com/expressjs/expressjs.com/pull/1490

Hi @RaminHaghi, thanks for reporting this. We already have a PR(#1621) to solve this issue, so I will close this issue since it's a duplicate of #1508.


Atom crashed when drag file into from network location

[Environment]
Windows 8.1 64bit
[Reproduction Steps]

Install and run latest atom 1.4.0, no extra package installed.
Make sure project folder closed in tree view.
Drag a file from network mapped driver or remote shared folder into atom.

[Expected Behavior]
File opened and new project folder created.
[Observed Behavior]
Atom crashed. (screen shot and crash log attached)
Capture.zip
Atom Crashes.zip
[Installed packages]
No extra package, all built-in Atom packages.
[Additional information]
Issue can be reproduced in safe mode.
Issue has a fail rate to happen, but easy to see when directory depth is deep on network location. I suspect it's related to connection timeout or remote path info. cache not ready.

Attach the crash dump analysis, looks hit access violation in git.node module:
FAULTING_IP:
git+5a14a
0f14a14a 8b07            mov     eax,dword ptr [edi]
I don't have symbol but from export table, it looks like in function git_pathspec_match_list_failed_entry.

Primary Analysis::
Windows 8 Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.3.9600.17415 (winblue_r4.141028-1500)
Machine Name:
Debug session time: Mon Jan 18 21:48:47.000 2016 (UTC - 5:00)
System Uptime: not available
Process Uptime: 0 days 0:00:09.000
Kernel time: 0 days 0:00:00.000
User time: 0 days 0:00:03.000
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\oca.ini, error 2
TRIAGER: Could not open triage file : e:\dump_analysis\program\winxp\triage.ini, error 2
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\user.ini, error 2

                                                                        *

                   Exception Analysis                                   *

                                                                        *

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\guids.ini, error 2
*** WARNING: Unable to verify timestamp for atom.exe
*** ERROR: Module load completed but symbols could not be loaded for atom.exe
*** WARNING: Unable to verify timestamp for node.dll
*** ERROR: Module load completed but symbols could not be loaded for node.dll
Unable to load image C:\Users\huanxu\AppData\Local\atom\app-1.4.0\resources\app.asar.unpacked\node_modules\pathwatcher\build\Release\pathwatcher.node, Win32 error 0n2
*** WARNING: Unable to verify timestamp for pathwatcher.node
*** ERROR: Module load completed but symbols could not be loaded for pathwatcher.node
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2
*** The OS name list needs to be updated! Unknown Windows version: 6.3 ***
FAULTING_IP:
git+5a14a
0f14a14a 8b07            mov     eax,dword ptr [edi]
EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0f14a14a (git+0x0005a14a)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
DEFAULT_BUCKET_ID:  NULL_POINTER_READ
PROCESS_NAME:  atom.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
 Will submit fix see if can be merged.

Can be fixed in libgit2.
https://github.com/libgit2/libgit2/pull/3585

Root cause addressed...
https://github.com/libgit2/libgit2/issues/3588

Re-title to describe the real issue..

Fixed in https://github.com/libgit2/libgit2/pull/3619

Issue has been fixed in libgit2 v0.24.0.
https://github.com/libgit2/libgit2/releases/tag/v0.24.0

Getting git-utils onto 0.24.0 is out for PR at https://github.com/atom/git-utils/pull/71


add-uv-pip-replacement

This PR adds an option to enable the new uv pip drop in replacement for installing requirements and creating a virtual environment.

Could you also add a test to tests?

Thank you!


Bug with side scroll bar in the script tab of the editor

Built on 07 April 2015
OS: Fedora 21
The side scroll bar within the script tab of the editor seems to have a limit at 70 columns even when the code line is longer. You can only access columns > 70 if you mark and drag the code with the mouse or by maximizing the window.
When maximizing, the side-scroll bar disappears completely. If the code line is bigger then the screen, you have to use above mentioned method with the mouse.
Little demo video:
https://youtu.be/eaTYeD1iIws

There is also a problem with the vertical scrollbar, its position is not always correctly restored during a tab change, and otherwise it's not possible to select and scroll in the same time.

I can't reproduce this issue in the current master branch (on Linux X11), so I'll assume it is fixed. Feel free to reopen or ask me to reopen if you can still reproduce it (it might be platform-dependent).


Cannot find libvlcjni.so

Hello,
First of all, thank you for the project. I'm having an issue when running an app that I'm testing where it says that cannot find some libraries:
08-08 04:06:18.552 W/VLC/LibVLC(10611): Unable to load the anw library: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/MyApp.MyApp-1/base.apk"],nativeLibraryDirectories=[/data/app/MyApp.MyApp-1/lib/x86, /vendor/lib, /system/lib]]] couldn't find "libanw.21.so"
08-08 04:06:18.552 E/VLC/LibVLC(10611): Can't load vlcjni library: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/MyApp.MyApp-1/base.apk"],nativeLibraryDirectories=[/data/app/MyApp.MyApp-1/lib/x86, /vendor/lib, /system/lib]]] couldn't find "libvlcjni.so"
What do you think that can be happening? Any suggestions?
Thank you again.

I think you are trying to run it in simulator or x86 device. This only supports ARM currently.