sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Engine does not handle OOM well
Labels: c: crash,engine,c: performance,perf: memory,P3,team-engine,triaged-engine

When we run out of memory, we just crash. There's no clear indication of what the problem is. `flutter run` just says the application finished after printing `W/ActivityManager:   Force finishing activity com.yourcompany.foo/org.domokit.sky.shell.SkyActivity` a couple of times, but doesn't quit. On the device, Android shows a material dialog that says "foo has stopped" with a single button "Open app again".

Here's an app that demonstrates the problem:

``` dart
import 'package:flutter/widgets.dart';

void main() {
  runApp(new CustomPaint(painter: new Painter()));
}

class Painter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final Paint paint   =   new Paint()
      ..color = const Color(0xFFEE9944);
    while (true)
      canvas.drawRect(new Rect.fromLTWH(10.0, 10.0, 10.0, 10.0), paint);
  }
}
```

Ideally we'd dump a stack trace of the currently running Dart code, at least.
Repository: go
Issue: runtime: gdb command "goroutine 1 bt" fails on core file
Labels: NeedsFix,Debugging,compiler/runtime

### What version of Go are you using (`go version`)?

go version go1.5.3 linux/amd64
### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/ldata/comp/project/go"
GORACE=""
GOROOT="/ldata/bin/go"
GOTOOLDIR="/ldata/bin/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
### What did you do?
1. export GOTRACEBACK=crash
2. ulimit -c unlimited
3. write a buggy program and run it to generate a core file
4. use gdb to load core file
5. source runtime-gdb.py
6. run `goroutine 1 bt`

### What did you expect to see?

print stack trace of goroutine 1
### What did you see instead?

print error msg:
    Python Exception <class 'gdb.error'> You can't do that without a process to debug.: 
    Error occurred in Python command: You can't do that without a process to debug.
Repository: rust
Issue: Compiler switch to list bound checks
Labels: I-slow,C-enhancement,T-compiler,C-feature-request

This is my first Rust enhancement request.

With the Go language compiler version 1.7, you can build the code using -gcflags="-d=ssa/check_bce/debug=1" to show which code lines still need checking bounds:

http://www.tapirgames.com/blog/golang-1.7-bce

Finding where the compiler is not able to optimize away run-time bound checks is important for some kinds of code where performance matters:

https://github.com/rust-lang/rust/pull/30917

Currently to do that in Rust I have to generate the asm with --emit asm, search the function(s) (this sometimes is not so easy because of inlining) and then read the asm to understand if and where it performs bound checks. This is a bit laborious and not handy. So is it possible to add to Rustc a compilation switch similar to Go that outputs all the lines and column where LLVM isn't able to remove array bound tests?

```
In-bound test(s):
16 | foo[i] -= 1;
         ^

32 | foo[i] += bar[j];
         ^         ^
```

(Having this compiler switch is only about one third of this performance battle).
Repository: go
Issue: net/http/cookiejar: add way to access all cookies in CookieJar
Labels: Suggested,help wanted,FeatureRequest

Please answer these questions before submitting your issue. Thanks!
### What version of Go are you using (`go version`)?

1.6.3
### What operating system and processor architecture are you using (`go env`)?

darwin / amd64
### What did you do?

Tried to access _all_ cookies stored in a [http.CookieJar](https://golang.org/pkg/net/http/cookiejar/#Jar.Cookies).
### What did you expect to see?

A Function for accessing the `[]*http.Cookie` data. The cookiejar struct is missing a way to access all the cookie structs saved in it. You have to know all the matching urls (as url.URL structs) in order to pull cookies out of it.
### What did you see instead?

Only a method for [reading cookies](https://golang.org/pkg/net/http/cookiejar/#Jar.Cookies) from pre-known url.URL structs.
Repository: youtube-dl
Issue: Piping to stdout writes to a file instead of stdout with some format specifier
Labels: bug

## Please follow the guide below
- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your _issue_ (like that [x])
- Use _Preview_ tab to see how your issue will actually look like

---
### Make sure you are using the _latest_ version: run `youtube-dl --version` and ensure your version is _2016.10.25_. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2016.10.25**
### Before submitting an _issue_ make sure you have:
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
### What is the purpose of your _issue_?
- [x] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

Piping to stdout does not work when using format `bestvideo+bestaudio/best`. It downloads to a file named `-.ext`.

For example :
`$ youtube-dl -v -f bestvideo+bestaudio/best -o - 'https://www.youtube.com/watch?v=0YSEagC7tsI' | mpv` 

It works without the above format specifier although ironically it is documented to be the default.

I noticed this because I have `-f bestvideo[width<=?1920]+bestaudio/best` in my youtube-dl config file, but I expected it to use the format which does not require merging when piping.
Repository: flutter
Issue: Some of our controls can't handle being built in 0x0 environments
Labels: a: tests,framework,f: material design,good first issue,P2,team-design,triaged-design

We should create tests that put each UI control into a 0x0 container and make sure they don't crash.

See https://github.com/flutter/flutter/pull/6535.
Repository: TypeScript
Issue: JSDoc support for destructured parameters
Labels: Suggestion,In Discussion,Help Wanted,VS Code Tracked,Domain: JSDoc

**TypeScript Version:**  2.0.3

**Code**

``` ts
interface Foo {
    /**
     * A bar value
     */
    bar?: string;
}

/**
 * A function
 *
 * @param foo A param
 * @param { bar } Another param
 * @param bar Another param
 */
function foo(foo: string, { bar }: Foo): void {
    bar;
    foo;
}

foo('bar', { bar: 'play' });
```

**Expected behavior:**

Intellisense for the second argument, or the second argument properties.

**Actual behavior:** 

No way of providing a description for the destructured elements of a destructured parameter.

![destructured](https://cloud.githubusercontent.com/assets/1282577/19733834/2adf8086-9b9d-11e6-945c-63136ded02d2.gif)
Repository: go
Issue: syscall: add support for Windows job objects
Labels: help wanted,OS-Windows,NeedsInvestigation,FeatureRequest

I would like to reopen #6720.
I excitedly read all the thread, ending with the greatest facepalm I had in the past years.

Look, this is not a solution!
If `nodejs` knows how to pass these signals between processes on windows - then no reason that `golang` should not. No magic involved.

Full story bellow.
Mind that if the `go` shim is out of the loop - it works as expected, so I deduct it has to be something that `golang` does wrong.

I would appreciate your input on this...
### What version of Go are you using (`go version`)?

donno. the one that `nodist@0.8.7` uses
### What operating system and processor architecture are you using (`go env`)?

Windows 10, x64
### What did you do?

I'm using `nodist` which allows me to run different versions of nodejs side by side.
`nodist` uses a shim layer of `go` to have a look around on the env vars and local folder to detect the desired node version and call the relevant executable accordingly

See here: 
https://github.com/marcelklehr/nodist/issues/179
### What did you expect to see?

https://github.com/marcelklehr/nodist/issues/179
### What did you see instead?

https://github.com/marcelklehr/nodist/issues/179
Repository: go
Issue: encoding/json: ambiguous fields are marshalled
Labels: NeedsDecision

Embedded fields work, even when there are selectors that are the same:
ex: https://play.golang.org/p/fJTGL-HWEk
You get a compile time error though when you select ambiguously:
ex: https://play.golang.org/p/McjVYbnAhT
I understand that it would be hard to achieve, but I expect a compile time error from the following code, but I don't get one:
https://play.golang.org/p/2oOXH2uzWy

I understand that others might rely on this inconsistency now, but if a compile time error is achievable (I understand that this would be difficult), it will be the least offensive fix possible.
Repository: go
Issue: all: spelling inconsistency for networking terms
Labels: Documentation,help wanted,NeedsFix

Some packages use `hostname` and others `host name`. The worst is the net package which uses both. It might be better to align to `host name` defined in https://tools.ietf.org/html/rfc7719.

```
Host name: This term and its equivalent, "hostname", have been
widely used but are not defined in [RFC1034], [RFC1035], [RFC1123], or [RFC2181]. 
```
Repository: TypeScript
Issue: auto align colons in object literals, variables, and equals like WebStorm
Labels: Suggestion,Awaiting More Feedback,VS Code Tracked

_From @kinergy on October 17, 2016 2:56_
- VSCode Version: 1.6.1
- OS Version: macOS 10.12

Using Format Code on a js file:

```
var abcde = 'abcde',
    def   = {
      a : 'aaa',
      bb: 'b'
    };
```

turns into:

```
var abcde = 'abcde',
  def = {
    a: 'aaa',
    bb: 'b'
  };
```

It would be really nice to have a setting to align the beginning of var names, align the equals, and align the colons in object literals like WebStorm. I tried looking for an extension, but wasn't able to identify one.

_Copied from original issue: Microsoft/vscode#13841_
Repository: bitcoin
Issue: Unbounded reorg memory usage
Labels: Resource usage

#9014 brought to light in issue introduced in #7946 - when we do a reorg, we now keep the full contents of each block we connect in memory until the reorg is complete. Luckily, #9014 makes this a bit eaiser to fix - dont keep more than a few blocks around in shared_ptrs, just re-read them from disk after the reorg is complete when you need to call signalers. This may be complicated due to pruning, but it should be doable.
Repository: go
Issue: cmd/compile: optimize functions into boolean expressions
Labels: Performance,compiler/runtime

Using 587b80322c6ce34ab115d7a837a56d7450aa913d

In http://golang.org/cl/32122, I optimized a switch-based implementation to be a boolean expression. The two implementations below are semantically equivalent:

``` go
func ValidRune1(r rune) bool {
    switch {
    case r < 0:
        return false
    case surrogateMin <= r && r <= surrogateMax:
        return false
    case r > MaxRune:
        return false
    }
    return true
}

func ValidRune2(r rune) bool {
    return (0 <= r && r < surrogateMin) || (surrogateMax < r && r <= MaxRune)
}
```

Testable benchmark: https://play.golang.org/p/KMlv43EVQn
The benchmark results:

```
benchmark        old ns/op     new ns/op     delta
BenchmarkA-4     16.3          11.9          -26.99%
```

We could consider having the compiler recognize the pattern of switch (with boolean expression as cases) and all return values are either boolean literals or expressions and have the compiler automatically optimize that into a single larger boolean expression.

\cc @bradfitz @minux @martisch
Repository: opencv
Issue: solve CV_SVD very slow in the latest opencv
Labels: incomplete

I'm on one of the most recent revisions of opencv (compiled from source): 1ae27eb6967f98c78c741539afb1d2de6a0bb322
(I compiled it with opencv_contrib if that matters).

Once I moved from official release to the one I mentioned earlier, matrix decomposition became really slow (10^3 slower!).

```
solve(X, Y, res, CV_SVD);
```

Please find X and Y matrices in attachment, hope it helps to reproduce the issue.
[data.txt](https://github.com/opencv/opencv/files/556422/data.txt)
Repository: go
Issue: cmd/compile: use better code for slicing
Labels: Performance,compiler/runtime

```
func f(s []int, i int) []int {
    return s[i:]
}
```

The assembly starts out with

```
MOVQ    "".i+32(FP), AX
MOVQ    "".s+16(FP), CX
CMPQ    AX, CX
JHI $0, 60
SUBQ    AX, CX
```

The CMP and SUB are almost redundant.  Instead, we could do

```
MOVQ    "".i+32(FP), AX
MOVQ    "".s+16(FP), CX
SUBQ    AX, CX
JHI $0, 60
```

We just need a subtract that also generates flags. (We have a 32-bit one for synthesizing 64-bit ops.  We need a 64-bit one also.)
Repository: TypeScript
Issue: disallow comparing to null and undefined unless they are valid cases in strict null mode
Labels: Suggestion,Awaiting More Feedback,Has Repro

the rationale is the same as for `--noUnusedLocals` which in this case would be `--noUselessNullChecks` (i am not proposing a new flag, the existing `--strictNullChecks` flag should be used, this is for illustration only)

``` typescript
declare const value: number;
if (value !== null) { // <-- somehow valid, expected to be invalid, since number doesn't have null as a possible value
}
if (value !== '') { // <-- invalid as expected 
}
```
Repository: opencv
Issue: conflicting typedef for int64
Labels: category: build/install,RFC,future

##### System information (version)
- OpenCV => 2.4.9 (2.4.9.1+dfsg-1.5ubuntu1)
- Operating System / Platform => Ubuntu 16.04, 64 bit
- Compiler => GNU GCC 5.2
##### Detailed description

OpenCV has typedef in global namespace that will prevent compilation if other library has conflicting typedef. Currently, we are aware of one library (libgeos) that has conflicting typedef. We are going to submit similar bug report to libgeos.

``` .cpp
// libgeos
typedef long long int int64;
// opencv
typedef int64_t int64;
```

I am aware that this problem could be solved by compiling code in different compilation unit, but currently we have shared code that can't be separated (or at least not easily)  in different compilation units. The only option in that case is to either mess with typedef, i.e.:

``` .cpp
#define int64 opencv_broken_int
#include <opencv2/imgproc/imgproc.hpp>
#undef int64
#include <geos/geom/Coordinate.h>

int main(int, argc**)
{
    return 0;
}
```

or make wrapper interface and compile it different compilation units. Nevertheless, the nicest solution would be if opencv could stop using common typename like int64 in global namespace. 

I am aware that using C++ namespace might not be option due to C interface, but at least prefixed typedef could be used, i.e. opencv_int64 / cv_int64 or similar. Such typedef would not break ABI, although it would change API.

We are ready to commit resources to this issue and provide a patch once we agree that this should be fixed and agree what is best approach to this issue. 
##### Steps to reproduce

``` .cpp
// sample.cpp
#include <geos/geom/Coordinate.h>
#include <opencv2/imgproc/imgproc.hpp>

int main(int, argc**)
{
    return 0;
}
```

```
$ g++ -c sample.cpp 
In file included from /usr/include/opencv2/core/core.hpp:49:0,
                 from /usr/include/opencv2/imgproc/imgproc.hpp:50,
                 from sample.cpp:2:
/usr/include/opencv2/core/types_c.h:163:20: error: conflicting declaration ‘typedef int64_t int64’
    typedef int64_t int64;
                    ^
In file included from /usr/include/geos/geom/Coordinate.h:19:0,
                 from sample.cpp:1:
/usr/include/geos/platform.h:66:26: note: previous declaration as ‘typedef long long int int64’
    typedef long long int int64;
                          ^
sample.cpp:4:15: error: ‘argc’ has not been declared
 int main(int, argc**)
               ^
sample.cpp:4:5: warning: second argument of ‘int main(int, int**)’ should be ‘char **’ [-Wmain]
 int main(int, argc**)

```
Repository: go
Issue: cmd/go: wrong import stack in error message
Labels: NeedsFix

This is not true:

```
$ go get -u rsc.io/github/issue
package rsc.io/github/issue
    imports 9fans.net/go/acme
    imports 9fans.net/go/plan9
    imports 9fans.net/go/plan9/client
    imports 9fans.net/go/draw
    imports 9fans.net/go/draw/drawfcall
    imports github.com/google/go-github/github
    imports github.com/google/go-querystring/query
    imports golang.org/x/net/context: exit status 1
... error about x/net checkout being in a bad state ...
```

It looks like imports are being pushed on the import stack and not being popped correctly. rsc.io/github/issue imports github.com/google/go-github/github directly. 9fans.net/go/draw/drawfcall does not.
Repository: youtube-dl
Issue: Forbes video download (hosted on Brigthcove)
Labels: site-support-request

Possible to add? example: http://www.forbes.com/video/5118388570001/
Repository: youtube-dl
Issue: site-support in youtube-dl for ozee.com site- streaming video only in flash though. 
Labels: site-support-request,geo-restricted

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2016.10.26**
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [x] Site support request (request for adding support for a new site)

---
## I would like to have support for ozee.com . 

This is what i get when I try/tried using youtube-dl -

```
[$] youtube-dl --verbose -F "http://www.ozee.com/shows/little-lord/video/little-lord-episode-23-october-28-2016-full-episode.html"  [3:13:25]
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'--verbose', u'-F', u'http://www.ozee.com/shows/little-lord/video/little-lord-episode-23-october-28-2016-full-episode.html']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.10.26
[debug] Python version 2.7.12+ - Linux-4.7.0-1-amd64-x86_64-with-debian-stretch-sid
[debug] exe versions: ffmpeg 3.1.4-1, ffprobe 3.1.4-1, rtmpdump 2.4
[debug] Proxy map: {}
[generic] little-lord-episode-23-october-28-2016-full-episode: Requesting header
WARNING: Falling back on generic information extractor.
[generic] little-lord-episode-23-october-28-2016-full-episode: Downloading webpage
[generic] little-lord-episode-23-october-28-2016-full-episode: Extracting information
ERROR: Unsupported URL: http://www.ozee.com/shows/little-lord/video/little-lord-episode-23-october-28-2016-full-episode.html
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 1634, in _real_extract
    doc = compat_etree_fromstring(webpage.encode('utf-8'))
  File "/usr/local/bin/youtube-dl/youtube_dl/compat.py", line 2525, in compat_etree_fromstring
    doc = _XML(text, parser=etree.XMLParser(target=_TreeBuilder(element_factory=_element_factory)))
  File "/usr/local/bin/youtube-dl/youtube_dl/compat.py", line 2514, in _XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1653, in feed
    self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1517, in _raiseerror
    raise err
ParseError: not well-formed (invalid token): line 76, column 24
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 694, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 356, in extract
    return self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 2417, in _real_extract
    raise UnsupportedError(url)
UnsupportedError: Unsupported URL: http://www.ozee.com/shows/little-lord/video/little-lord-episode-23-october-28-2016-full-episode.html
```
Repository: go
Issue: archive/tar: add Reader.NextRaw method to read only one raw header
Labels: NeedsInvestigation,FeatureRequest

The current master implementation [elides records](https://github.com/golang/go/blob/ee457118cd7b11264719647fa6f7422bac2a4431/src/archive/tar/reader.go#L117-L121), for example pax `x` typeflag records are collapsed  into the following record with the extended headers being [merged into the normal file's headers](https://github.com/golang/go/blob/ee457118cd7b11264719647fa6f7422bac2a4431/src/archive/tar/reader.go#L168-L170).  This is useful for most consumers, who are only interested in consuming the tar content.  But two use cases would benefit from more direct access to the lower-level tar details:
- Accessing information that is not yet represented in the the tar structure.  For example, `tar.Header` does not currently expose pax extended headers outside of [these names and prefixes](https://github.com/golang/go/blob/ee457118cd7b11264719647fa6f7422bac2a4431/src/archive/tar/common.go#L175-L191).  There are plans to rectify this limitation (#14472), but until the tar structures expose all of these sorts of details it will be useful to have a way to directly access the header and file data.  This will allow users to add their own parsers for any extension they need which is not yet supported by the stdlib, without requiring them to fork archive/tar or replace it with a completely novel parser.
- Validating tar files against a particular standard.  If a protocol places requirements on the tar elements, users will need more direct access to the tar details to check the tar file against those requirements.  For an example along these lines, see opencontainers/image-spec#342 and the extremely naive stub [here](https://github.com/wking/image-tools/commit/4f0b3c1bae97d212680dc73ee8b35b6e47b8a8c6#diff-201d416d61af62a246e5b552b6d42c92R60) (which currently doesn't work because `Next()` never returns the `x` typeflag headers).

I think we can address both of these cases without breaking the existing API with two changes:
1. Adding a `tar.Reader.NextRaw()` that works like `tar.Reader.Next()`, but always returns the next record regardless of its typeflag.
2. Adding `tar.Header.Bytes` exposing a `[]byte` slice of the raw header data, to allow clients to access header fields that are not yet mapped to other `tar.Header` attributes.  Alternatively, this could be a method `tar.Header.Bytes()` (or an attribute exposing a `string` or whatever) to make the data clearly read-only.

Folks who wish to control writing at a low level may want similar changes on the `tar.Writer` side, but I think that is orthogonal enough to punt to a separate issue (if anyone wants it).

CC @dsnet.