sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: Secure memory: Yay or nay
Labels: memory,security

OpenSSL has support for a concept that is referred to as _secure memory_ or _secure heap_. Essentially, every time OpenSSL allocates memory, it indicates whether that memory should be allocated from the "normal" heap using `malloc` or from the "secure" heap. Allocations on the secure heap usually have the following security properties:

- Allocated memory is never swapped to the disk and never included in core dumps, making it less likely to leak sensitive information through those.
- Allocated memory is always overwritten on deallocation, also making it less likely to leak information.
- It is far more difficult to use buffer overflows to retrieve data from these allocations. (OpenSSL causes the process to terminate if memory surrounding secure allocations is accessed.)

Node.js does not use this feature, meaning that OpenSSL performs normal allocations. (OpenSSL still overwrites the memory on deallocation.) We can enable OpenSSL's implementation, but it is quite restrictive and will be difficult to configure for users of Node.js. The alternative is to provide a more suitable implementation within Node.js, which provides similar security properties while being easier to use and less restrictive. However, that requires:

- Upstream changes to OpenSSL's memory management, in order to allow overriding the built-in secure memory implementation. I have talked to some of the maintainers, and they would likely accept such changes.
- The actual secure heap implementation in Node.js. That is not super difficult, but the implementation is platform-specific and will not be easy to test.

I started working on this approach about a year ago, and never finished it. I got varying feedback at the Montreal summit, so let's discuss this in public before I either stop working on it or put in a lot more work. As someone pointed out, many cloud applications likely don't care about this level of security.

Even if we upstream the necessary changes in OpenSSL, it is unlikely to ever work with a shared OpenSSL library, so dynamic linking would disable the feature. Also, I don't want to break Electron (as I have done numerous times, sorry @codebytere!), so we would need to make sure to either propose the change to both OpenSSL and BoringSSL or to make it easy to opt out of the feature at compile time.

I also have a patch that solves https://github.com/nodejs/node/issues/18896, but relies on this particular feature, and is super dangerous to use.
Repository: flutter
Issue: [video_player] Videos don't play in Safari/Chrome on iOS 
Labels: customer: crowd,platform-web,p: video_player,package,has reproducible steps,customer: web10,customer: ninja,P2,found in release: 2.1,browser: safari-ios,team-web,triaged-web

video_player_web,video_player can play in Mac safari normaly by platform web, but when I play in phone safari, it doesn't work.
Repository: rust
Issue: `--emit=[asm|llvm-bc|llvm-ir|obj]` not emitting allocator or metadata
Labels: A-codegen,A-metadata,T-compiler,C-feature-request

At present, `rustc --emit=[asm|llvm-bc|llvm-ir|obj]` only generates artifacts of the regular module but not allocators or metadata.

While working on #64191 , I found such behavior was very confusing as I expected it to output all artifacts I need to generate the final binary.  Therefore, I am proposing to make `rustc --emit=[asm|llvm-bc|llvm-ir|obj]` emits allocators and metadata, in addition to the regular module. For example:
- `rustc --emit=llvm-bc foo.rs` would outputs `foo.bc` and `foo.allocator.bc` [crate-type bin doesn't need metadata]
- `rustc --emit=llvm-ir foo.rs --crate-type=dylib` would outputs `foo.ll`, `foo.allocator.ll`, and `foo.metadata.ll`
Repository: rust
Issue: `--emit=metadata` emitting empty .rmeta file
Labels: A-metadata,T-compiler

At present, `rustc --emit=metadata foo.rs` generates an empty rmeta file named `libfoo.rmeta`. The logic behind is that [rmeta is not needed for certain crate types](https://github.com/rust-lang/rust/blob/12307b3b08edee543a78fb9d4a837fbd6d6ac0fa/src/librustc_interface/passes.rs#L922-L939). However, I feel we should still save it to a file when user explicitly requested it by `--emit=metadata`, especially the metadata is always available in memory regardless of output crate types.
Repository: youtube-dl
Issue: --playlist--start and --playlist-end more verbosity suggestion
Labels: request

## Checklist
- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2019.11.28**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description
While using `youtube-dl <playlisit-id> --playlist-start 10` on a playlist containing 60 videos, `youtube-dl` displays 50 videos in playlist and counts them from 1 to 50 (_Downloading video 1 od 50_). When user does not know the exact count of videos in playlist, they don't know if `--playlist-start` works or not. There is no indication of that whatsoever.

My idea is to show more verbose info when using `--playlist--start` and `--playlist-end`. Assuming one is running `youtube-dl <playlisit-id> --playlist-start 10 --playlist-end 30` on a playlist mentioned earlier, the message could be as follows:

```
...
[youtube:playlist] playlist <playlist-name>: Downloading 20 out of 60 videos
[download] Downloading video 1 of 20 (playlist video 10)
...
```

This way the user gets two important pieces of information:
1. The `--playlist--start` and `--playlist-end` switches do work,
2. In case a download fails somewhere in the middle of the queue, the `playlist video nn` on `[download]` line tells exactly with what `--playlist--start` index should the download be re-started

I believe this change won't require much work, but the result would pretty big for users.
Repository: pytorch
Issue: Intel OMP multiprocessing assertion failure: Assertion failure at z_Linux_util.cpp(2338)
Labels: module: dependency bug,module: multiprocessing,triaged

## 🐛 Bug

We observe a weird assertion happening after 4-12 hours of training an image classifier with pytorch nightly and intel omp 2019.4, one of data loader workers fails with this error:

```
OMP: Error #13: Assertion failure at z_Linux_util.cpp(2338).
OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/.
...
in update
    v = v.item()
  File "/private/home/szagoruyko/miniconda3/envs/pytorch-nightly/lib/python3.7/site-packages/torch/utils/data/_utils/signal_handling.py", line 66, in handler
    _error_if_any_worker_fails()
RuntimeError: DataLoader worker (pid 42786) is killed by signal: Aborted.
```

downgrading to intel-omp 2019.1 seemingly fixes the issue.

Also found this issue https://github.com/ContinuumIO/anaconda-issues/issues/11294 but it looks like it's not present in 2019.4

(cc: discussed offline with @fmassa and @pietern )

## Environment

```
PyTorch version: 1.4.0.dev20191112
Is debug build: No
CUDA used to build PyTorch: 9.2

OS: Ubuntu 18.04.1 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.10.2

Python version: 3.7

Nvidia driver version: 410.79
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy==1.17.3
[pip] torch==1.4.0.dev20191112
[pip] torchfile==0.1.0
[pip] torchnet==0.0.4
[pip] torchvision==0.5.0a0+bfd4b2a
[pip] torchviz==0.0.1
[conda] blas                      1.0                         mkl
[conda] mkl                       2019.4                      243
[conda] mkl-service               2.3.0            py37he904b0f_0
[conda] mkl_fft                   1.0.15           py37ha843d7b_0
[conda] mkl_random                1.1.0            py37hd6b4f25_0
[conda] pytorch                   1.4.0.dev20191112 py3.7_cuda9.2.148_cudnn7.6.3_0    pytorch-nightly
[conda] torchfile                 0.1.0                    pypi_0    pypi
[conda] torchnet                  0.0.4                    pypi_0    pypi
[conda] torchvision               0.5.0.dev20191112       py37_cu92    pytorch-nightly
[conda] torchviz                  0.0.1                     dev_0    <develop>
```

cc @SsnL
Repository: flutter
Issue: Support toggling window decoration visibility on desktop
Labels: c: new feature,engine,platform-mac,platform-windows,platform-linux,a: desktop,P3,team-macos,triaged-macos

## Use case
A Flutter application running on desktop should be able to control its decoration or its frame, that is to show or hide the surrounding window frame which typically holds the title and close icon.
Repository: opencv
Issue: cudaGLSetGLDevice deprecated errors
Labels: category: gpu/cuda (contrib)

In building OpenCV 4.1.2 with OpenGL and CUDA enabled, I'm seeing warnings about the function
cudaGLSetGLDevice being deprecated.  It is called in opengl.cpp.  Is this a known problem, or is it something that results from a certain combination of flags?

In opengl.cpp:
```
void cv::cuda::setGlDevice(int device)
{
#ifndef HAVE_OPENGL
    CV_UNUSED(device);
    throw_no_ogl();
#else
    #ifndef HAVE_CUDA
        CV_UNUSED(device);
        throw_no_cuda();
    #else
        cudaSafeCall( cudaGLSetGLDevice(device) );
    #endif
#endif
}

```
Repository: godot
Issue: Joints Gizmos disappear after switching scenes tab in Editor 
Labels: bug,topic:editor,confirmed,usability,topic:3d

**Godot version:**
Godot 3.2 Beta 3

**OS/device including version:**
Windows 7 x64bit

**Issue description:**
Joints Gizmos disappear after switching scenes tab in Editor 
**Steps to reproduce:**
1 - Create a Physical skeleton from your skeleton 
2 - Select your Physical Bones and Change the Joint Type for Example to : ConeJoint
3 - Switch Scene tab and Go Back again to this scene , Joints Gizmos Disappears
4 - close that scene after saving it and re-open it again , joints Gizmos are back again
Repository: react
Issue: Controlled numeric input gets cleared when unfocused
Labels: Type: Bug,Component: DOM,Resolution: Backlog

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
I would like to report a bug.

**What is the current behavior?**
A numeric input field gets cleared accidentally on several occasions.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

1. Open [this sandbox](https://codesandbox.io/embed/sad-rgb-mltuj)
2. Type “12.” into the field, with the trailing decimal separator
3. Unfocus the control
4. Append “.” to the field’s value to see “12..”
5. Unfocus the control once again and see that the number has completely disappeared

**What is the expected behavior?**

Similar to how uncontrolled inputs work (remove the `value` prop and then repeat the steps above), the input should not be cleared on blur.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

I’m using React 16.12.0 and experienced the same behavior with the latest version of Chrome and iOS Safari. Regarding this bug, I have no experience with previous versions of React.
Repository: rust
Issue: RcFromIter and ArcFromIter have unused specializations
Labels: T-libs-api,A-specialization,C-bug,A-iterators

[`RcFromIter`](https://github.com/rust-lang/rust/blob/1.39.0/src/liballoc/rc.rs#L1498-L1543) and [`ArcFromIter`](https://github.com/rust-lang/rust/blob/1.39.0/src/liballoc/sync.rs#L2061-L2106) have three impls each:

- One is for a general `I: Iterator<Item = T>` (A)
- One is for `I: TrustedLen<Item = T>` (B)
- One is for `slice::Iter<'a, T>` (C)

The way `default` is specified suggests that (C) specializes (B) and (B) specializes (A).

However, in the impl (C), the iterator `slice::Iter<'a, T>` is `Iterator<Item = &'a T>`, not `Iterator<Item = T>`. I guess (C) is in fact an unrelated implementation that is exclusive to (A)?

As the only user of `RcFromIter` is `<Rc<[T]> as FromIterator>::from_iter` and the call looks like resolved to (A), (C) seems totally unused. I guess we want to implement `RcFromIter` for `iter::Cloned<slice::Iter<'a, T>>` and `iter::Copied<slice::Iter<'a, T>>` instead?

Moreover, the first type parameter `T` of `RcFromIter<T, I>` seems unnecessary too.
Repository: create-react-app
Issue: formatWebpackMessages clean up messages filename
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

when the error/warning contains `(loader?xxxxxx)` , the filename will display like this. 
```
/src/App.scss (/codes/test-appt/node_modules/css-loader/dist/cjs.js??ref
--7-oneOf-5-1!/codes/test-appt/node_modules/postcss-loader/src??postcss!/codes/test-appt/node_mo
dules/resolve-url-loader??ref--7-oneOf-5-3!/codes/test-appt/node_modules/sass-loader/dist/cjs.js??ref--7-
oneOf-5-4!./config/stylelint-loader.js??ref--6-0!./src/App.scss)
```
![image](https://user-images.githubusercontent.com/6290356/70858755-1a231c80-1f43-11ea-8934-fe2382e70811.png)

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

when cleanup  the filename
https://github.com/facebook/create-react-app/blob/f26de73e645e30a030af716caf6f61bcda24ef08/packages/react-dev-utils/formatWebpackMessages.js#L63-L64

remove the loader info
```js
  lines[0] = lines[0].replace(/\s+\(.*\)$/, ''); // remove (loader?query....)
```
Repository: go
Issue: runtime: go1.13.5/go tip worst gc pause time increase from go1.9.7 in darwin/amd64
Labels: NeedsInvestigation,compiler/runtime

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.5 darwin/amd64
go version devel +7d30af8 Fri Dec 13 20:41:04 2019 +0000 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
yes.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/a/Library/Caches/go-build"
GOENV="/Users/a/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/a/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m9/qtbxkp6s3p96fk54rln7qhj80000gp/T/go-build165542294=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

### What did you do?
```
package main

import (
	"fmt"
	"time"
)

const (
	windowSize = 200000
	msgCount   = 1e7
)

type (
	message []byte
	buffer  [windowSize]message
)

var worst time.Duration

func mkMessage(n int) message {
	m := make(message, 1024)
	for i := range m {
		m[i] = byte(n)
	}
	return m
}

func pushMsg(b *buffer, highID int) {
	start := time.Now()
	m := mkMessage(highID)
	(*b)[highID%windowSize] = m
	_ = m
	elapsed := time.Since(start)
	if elapsed > worst {
		worst = elapsed
	}
}

func main() {
	var b buffer
	for i := 0; i < msgCount; i++ {
		pushMsg(&b, i)
	}
	fmt.Println("Worst push time: ", worst)
}
```
Code modified from https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

### What did you expect to see?
Worst gc pause time decrease or equal.

### What did you see instead?
Worst gc pause time increase.
```
go version go1.9.7 darwin/amd64:
Worst push time:  9.354054ms
Worst push time:  8.229477ms
Worst push time:  7.651093ms
Worst push time:  8.560363ms

go version go1.13.5 darwin/amd64:
Worst push time:  190.080638ms
Worst push time:  15.075733ms
Worst push time:  14.391396ms
Worst push time:  14.358026ms

go version devel +7d30af8 Fri Dec 13 20:41:04 2019 +0000 darwin/amd64
Worst push time:  12.889516ms
Worst push time:  14.144591ms
Worst push time:  12.965626ms
Worst push time:  14.668102ms
```
Repository: pytorch
Issue: torch runtime error when manual link libmkldnn.so
Labels: module: build,triaged,module: mkldnn

## 🐛 Bug

I manual link libmkldnn.so, because I want to use some functions inside mkldnn, but pytorch get runtime error when I manual link libmkldnn.so

## To Reproduce

Steps to reproduce the behavior:

```
import ctypes, os

mkl_lib_name="MY_MKL_PATH/lib/libmkldnn.so"
dlopen_flags = os.RTLD_NOW | os.RTLD_GLOBAL # | os.RTLD_DEEPBIND
ctypes.CDLL(mkl_lib_name, dlopen_flags)

nchw = [2, 3, 100, 100]
oihw = [4, 3, 5, 5]

import torch
m = torch.nn.Conv2d(3, 4, 5, 1, 2)
m(torch.rand(*nchw))
```
get runtime error
```
Traceback (most recent call last):
  File "a.py", line 13, in <module>
    m(torch.rand(*nchw))
  File "/usr/local/lib/python3.7/dist-packages/torch/nn/modules/module.py", line 541, in __call__
    result = self.forward(*input, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/torch/nn/modules/conv.py", line 345, in forward
    return self.conv2d_forward(input, self.weight)
  File "/usr/local/lib/python3.7/dist-packages/torch/nn/modules/conv.py", line 342, in conv2d_forward
    self.padding, self.dilation, self.groups)
RuntimeError: std::exception
```

## Expected behavior

No runtime error

## Environment
PyTorch version: 1.3.0
Is debug build: No
CUDA used to build PyTorch: 10.1.243

OS: Ubuntu 16.04.3 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
CMake version: version 3.5.1

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip3] numpy==1.17.3
[pip3] torch==1.3.0
[pip3] torchvision==0.4.1
[conda] Could not collect


cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh
Repository: neovim
Issue: ext_messages: msg_show("confirm_sub") is not always cleared
Labels: bug,ui-extensibility,messages

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: NVIM v0.5.0-241-g9f3d483c7
- Operating system/version: Linux 5.0.0-36-generic #39~18.04.1-Ubuntu X86_64

### Steps to reproduce using `nvim -u NORC`

1) Connect to neovim with a GUI, make sure to set `ext_messages` to true
2) Set the buffer's content to "This is a test"
3) Run `nvim_input(":%s/a/A/gc<CR>")`

Neovim will ask the GUI to draw the confirm prompt with the following message:
```json
[ "msg_show", "confirm_sub", [ [ 137, "replace with A (y/n/a/q/l/^E/^Y)?" ] ], false ]
```

Run `nvim_input("y")` and neovim will send the following message to clear the confirm prompt:
```json
[ "msg_showcmd", [] ]
```

Getting a `msg_showcmd` message instead of a `msg_clear` message is weird but I can work around that. However, if the user sets `noshowcmd`, neovim will not send a `msg_showcmd` event and the `confirm_sub` prompt will never be cleared (until a `msg_show` message is received, that is). This behavior differs from the TUI, where the prompt is always cleared, no matter what `showcmd` setting the user is using.

I wanted to write a small reproducer to help you confirm/test this bug but I wasn't sure where to start/how to implement tests for this behavior in neovim's testsuite.
Repository: TypeScript
Issue: EmitResolver cannot handle JsxOpeningLikeElement and JsxOpeningFragment that didn't originate from the parse tree
Labels: Bug,Help Wanted,Domain: Transforms,Rescheduled

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.7.x-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

Debug Failure. False expression., typescript transformer, jsx element

**Code**

- clone `https://github.com/madou/untitled-css-in-js-project`
- run `git checkout b229dc749e4614bb8d9194c8de340a82f10c8f8a`
- run `yarn`
- run `yarn test`
- [notice one test fails](https://github.com/madou/untitled-css-in-js-project/blob/b229dc749e4614bb8d9194c8de340a82f10c8f8a/src/transformers/__tests__/index.test.tsx#L6) `should not blow up when transforming with const`
- [notice a similar test but with](https://github.com/madou/untitled-css-in-js-project/blob/b229dc749e4614bb8d9194c8de340a82f10c8f8a/src/transformers/__tests__/index.test.tsx#L24) `var` instead of `const` passes

[the node transformation is done here](https://github.com/madou/untitled-css-in-js-project/blob/b229dc749e4614bb8d9194c8de340a82f10c8f8a/src/transformers/css-prop/visitors/visit-jsx-element-with-css-prop.tsx#L115) - if i return the original jsx element node then the test passes. but then that defeats the purpose of the transformer.. 😛 

the code is essentially transforming

```
const Component = () => <div css={{ fontSize: '20px' }}>hello world</div>;
```

to

```
const Component = () => (
<>
  <style>{'.a { font-size: 20px; } '}</style>
  <div className="a">hello world</div>
</>
);
```

**Expected behavior:**

it works no error thrown

**Actual behavior:**

`"Debug Failure. False expression."` error thrown. also tried with nightly typescript version - same error.

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

https://github.com/microsoft/TypeScript/issues/24380

😄  would love to get this figured out! hoping it's just something i've done wrong. make from this twitter thread https://twitter.com/orta/status/1206139333448732672
Repository: godot
Issue: AnimationPlayer track editor is missing click-and-drag timeline scrolling that was present in Godot 3.0
Labels: enhancement,topic:editor,confirmed,usability,regression,topic:animation

**Godot version:** 3.1.2 stable

**OS/device including version:** Win7

**Issue description:**
LMB click and drag on the timeline is no longer possible in 3.1, while it was possible in 3.0.6

3.1:
![drag_scroll_animpreview](https://user-images.githubusercontent.com/47016402/70862778-fd85e500-1f40-11ea-8806-d29eaf1daa65.gif)

3.0.6:
![timeline_scolling_3 0 6](https://user-images.githubusercontent.com/47016402/70862787-21492b00-1f41-11ea-9d6e-2e9ee8a0111b.gif)

**Steps to reproduce:**
Either zoom into the timeline or increase the animation length to something larger than the currently displayed time in the Animationpanel, LMB click and drag the timestamp on the timeline