sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [Android][Production]: Text based rendering crash
Labels: c: crash,platform-android,engine,a: production,P2,team-android,triaged-android

We have 1 user who is reporting the app is crashing randomly usually within a few seconds to almost a minute of starting the application. Problem is I have also tested this on the same hardware the user is reporting and cant reproduce it.  Also being that its an NDK crash I have no idea where to look.

They have reinstalled the application, cleared app data and cache and still cant figure this one out.

Reported into our Crash Monitor (DataDog RUM)

Device: Pixel 6 Pro (Android 13)
Flutter 3.3.7


NDK crash detected with signal: SIGSEGV

```
`0 [vdso] 0x7e186f9878 __kernel_rt_sigreturn + 2168

1 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a2bde0 + 6340064

2 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a2ebc8 + 6351816

3 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a2cf7c + 6344572

4 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a2b598 + 6337944

5 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a28c40 + 6327360

6 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab59eb8ec + 6076652

7 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5a47f00 + 6455040

8 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libflutter.so 0x7ab5b0fefc + 7274236

9 /data/app/~~ayni63v8ax5pWj0u9QNiEg==/com.app.flutter.core-UWzXQJgvw41Dcqka-m-arQ==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libapp.so 0x7ab01bbf60 _kDartVmSnapshotInstructions + 4960096`
```
Repository: flutter
Issue: Some emoji/text abnormal in different text orders
Labels: engine,a: typography,c: rendering,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-engine,triaged-engine

## Steps to Reproduce

I found some text/emoji not work, it have different result by order.
if "🆗" before "0️⃣ ", work fine. if not, it work abnormal.

here is sample code:
```
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Container(
            alignment: Alignment.center,
            padding: const EdgeInsets.all(16),
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children: const [
                Text(
                  '🆗0️⃣',
                ),
                Text(
                  '🆗a0️⃣',
                ),
                Text(
                  '0️⃣🆗',
                ),
                Text(
                  '0️⃣a🆗',
                ),
                Text(
                  '🆗',
                ),
                Text(
                  '0️⃣',
                ),
                Text(
                  'a0️⃣',
                ),
              ],
            )
        ),
      ),
    );
  }
}
```

```
[√] Flutter (Channel stable, 3.3.8, on Microsoft Windows [Version 10.0.19044.2251], locale zh-TW)
[√] Android toolchain - develop for Android devices (Android SDK version 32.0.0)                 
[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.11.10) 
[√] Android Studio (version 2021.3)                                             
[√] Connected device (2 available)
[√] HTTP Host Availability
```

Result:
<img src="https://user-images.githubusercontent.com/33835425/202337201-6ed976cf-106a-4311-8e10-a19dff00c84f.jpg" width="300"/>
Repository: flutter
Issue: "C-style casts are discouraged" google-readability-casting warnings
Labels: team,engine,P2,team-engine,triaged-engine

On Linux host 
```
❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/flow/layers/backdrop_filter_layer.cc:
/b/s/w/ir/cache/builder/src/flutter/flow/layers/backdrop_filter_layer.cc:45:63: error: C-style casts are discouraged; use static_cast/const_cast/reinterpret_cast [google-readability-casting,-warnings-as-errors]
      Layer::AutoPrerollSaveLayerState::Create(context, true, bool(filter_));

❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/impeller/renderer/backend/gles/shader_library_gles.cc:
/b/s/w/ir/cache/builder/src/flutter/impeller/renderer/backend/gles/shader_library_gles.cc:67:45: error: C-style casts are discouraged; use static_cast/const_cast/reinterpret_cast [google-readability-casting,-warnings-as-errors]
    functions[ShaderKey{key_name, stage}] = std::shared_ptr<ShaderFunctionGLES>(

❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/impeller/renderer/backend/vulkan/shader_library_vk.cc:
/b/s/w/ir/cache/builder/src/flutter/impeller/renderer/backend/vulkan/shader_library_vk.cc:88:45: error: C-style casts are discouraged; use static_cast/const_cast/reinterpret_cast [google-readability-casting,-warnings-as-errors]
    functions[ShaderKey{key_name, stage}] = std::shared_ptr<ShaderFunctionVK>(
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8797288801511583249/+/u/test:_lint_host_debug/stdout

See also https://github.com/flutter/engine/pull/36885

cc @gaaclarke
Repository: flutter
Issue: "do not use namespace using-directives; use using-declarations instead" google-build-using-namespace warnings
Labels: team,engine,P2,team-engine,triaged-engine

```
❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_binary_messenger.cc:
/b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_binary_messenger.cc:8:1: error: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace,-warnings-as-errors]
using namespace flutter::testing;
^

❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_settings.cc:
/b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_settings.cc:7:1: error: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace,-warnings-as-errors]
using namespace flutter::testing;
^

❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_text_input_view_delegate.cc:
/b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_text_input_view_delegate.cc:7:1: error: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace,-warnings-as-errors]
using namespace flutter::testing;
^

❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_im_context.cc:
/b/s/w/ir/cache/builder/src/flutter/shell/platform/linux/testing/mock_im_context.cc:7:1: error: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace,-warnings-as-errors]
using namespace flutter::testing;
^

etc
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8797288801511583249/+/u/test:_lint_host_debug/stdout
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8797288801518646705/+/u/test:_lint_host_debug/stdout
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8797288801518646689/+/u/test:_lint_ios_debug_sim/stdout


https://releases.llvm.org/13.0.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-build-using-namespace.html

See https://github.com/flutter/engine/pull/37698
Repository: ant-design
Issue: select下拉框功能优化
Labels: Inactive

### What problem does this feature solve?

1. 目前当下拉框被禁用的时候, 用户无法复制下拉框中的内容, 希望可以默认支持禁用的时候可复制的功能
2. 目前很多表单元素都默认支持reayOnly只读属性, 但是下拉框不支持, 希望可以支持一下这个功能

### What does the proposed API look like?

希望select props可以增加readOnly只读参数

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: [feature request] Add ability to preserve traced shape during torch.jit.save and torch.jit.load
Labels: oncall: jit

## Issue description

I would like to be able to access the shape information of a traced model after loading the traced version of a model. It is my understanding that this isn't always desirable so to preserve current workflows, I propose adding an optional parameter that defaults to false in torch.jit.load that will allow this information to be restored. I also understand that this can add more data to the saved model so I think that there should be a parameter that allows this information to be saved, but that it default to True so that this feature will work when loading models by default as in most models the extra space should be negligible.

## Code example
I would like to support the below example

 ```
import os
 import torch
 from torchvision.models import resnet50, ResNet50_Weights

 model=resnet50(weights=ResNet50_Weights.IMAGENET1K_V1)
 traced = torch.jit.trace(model, torch.rand(1, 3, 224, 224))
 traced.forward(torch.rand(1,3,224,224))
 input_sizes = [ x.type().sizes() for x in traced.graph.inputs() ]
 torch.jit.save(traced, "/tmp/resnet50pt")
 loaded = torch.jit.load("/tmp/resnet50pt", _retrace=True)
 loaded_input_sizess  = [ x.type().sizes() for x in loaded.graph.inputs() ]
 assert loaded_inputs == inputs
```

## System Info
This shouldn't be relevant in this case.

## Extra Notes
I'm already working on implementing this, just wanted to confirm that this seemed reasonable


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: next.js
Issue: Next ESLint does not match ESLint (App directory)
Labels: bug,Linting

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```
    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.13.0
      npm: 8.1.4
      Yarn: 1.22.17
      pnpm: N/A
    Relevant packages:
      next: 13.0.3
      eslint-config-next: 13.0.3
      react: 18.2.0
      react-dom: 18.2.0
```

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

Linting is not currently happening on the `/app` directory. I've added `prettier` and when testing with `yarn lint` it works on `/pages` directory however, it doesn't catch errors in the `/app` directory.

### Expected Behavior

`yarn lint` should provide the same linting errors as `yarn run eslint`

### Link to reproduction - Issues with a link to complete (but minimal) reproduction code will be addressed faster

n/a

### To Reproduce

```
yarn add eslint-config-prettier
yarn add eslint-plugin-prettier
yarn add prettier
```

`.eslintrc.json`:
```
{
  "extends": ["next/core-web-vitals", "prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error",
    "arrow-body-style": "off",
    "prefer-arrow-callback": "off"
  }
}
```

`.prettierrc.json`:
```
{
  "semi": false,
  "trailingComma": "es5",
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false
}
```

Then in the `/app` directory include semicolons and double quotes. You expect to see an ESLint error that comes from Prettier however, that is not the case. 

fwiw, a temporary fix is found in: https://nextjs.org/docs/basic-features/eslint#linting-custom-directories-and-files
Repository: TypeScript
Issue: Runtime error when static property initializer of a decorated class references the class
Labels: Needs Investigation

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

static initialization decorator runtime

### 🕗 Version & Regression Information

- Occurring in 4.8.4
- This changed between versions 4.5.5 and 4.6.4 when static properties started transpiling as [static initialization blocks](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Static_initialization_blocks)

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?target=9#code/MYewdgzgLgBAJgU2ALhgYQDYEMIQCJIgBOWUxMAvDMBhJQHzW0DcAsAFAACiwTOdAQRgBvGNFIBLXgA9KMMAgDuMIQF8gA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
const dec: ClassDecorator = cls => cls;
@dec class A { static x = new A }
```

### 🙁 Actual behavior

No compilation error as expected, but this generates a runtime error of "undefined is not a constructor".

### 🙂 Expected behavior

Either a compilation error, or no runtime error.
Repository: kubernetes
Issue: updating CRD causes connection loss with active watches of custom resources
Labels: kind/bug,area/apiserver,sig/api-machinery,area/custom-resources,triage/accepted

### What happened?

1. update CRD 's description fields
2. the client watching for the cr resource will lost watch https://github.com/kubernetes/kubernetes/pull/78029

### What did you expect to happen?

As i only chang the CRD's descriptions , this is not necessory to notify all client about the change.
This increase signifient pressure for kube-apiserver in large cluster.

### How can we reproduce it (as minimally and precisely as possible)?

update CRD fields, and you can see watch connection is lost

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.15-aliyun.1", GitCommit:"707e514954f0f3ba8ce36face7cf7058403057bc", GitTreeState:"clean", BuildDate:"2022-09-22T03:45:47Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
```

</details>

/sig api-machinery
Repository: stable-diffusion-webui
Issue: [Bug]: Generation is stuck at ~97% indefinitely when CLI Total Progress is at 100%
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Generations will sometimes get stuck on ~97% complete in the UI during generate/generate forever. During this period, the Total Progress in the CLI will have reached and remains at 100% for several minutes. During this 'stuck' period, the GPU is still under load, but usage % and temperatures gradually drop.

After encountering the bug a few more times, I believe this has something to do with the txt2img tab. Doing anything that reloads the it will resolve the 'stuck' state of the generation. This includes but is not limited to: refreshing the browser page, switching to different tabs (img2img, PNG Info, etc) then back to txt2img, and using the `Restart Gradio and Refresh Components` button.

The previously stuck generation will also promptly appear as a complete image in the /Output folder once any of the described actions above are taken. 

After a refresh/Image Browser page load, the generation will be able to begin as normal.

Given a long enough time, the UI will occasionally output the image, but the total time taken for a single generation is several times longer than normal (1 minute per image balloons to 8 minutes per image). Following that, the CLI `it/s` updates from a baseline of 1.5-3.5 iterations per second to a significantly slower value of ~8 to 10 seconds per iteration. This value was previously static once the generation gets stuck, and only updates once the image is outputted.

The below is a gif of the 97% stuck-100 % CLI complete bug. View in HD otherwise the gif is bloody small.

https://gfycat.com/grossdampbarasinga

### Steps to reproduce the problem

This bug is not consistently reproducible, I was unable to identify the cause. Once the first occurrence begins, it is likely to occur for the next few generations in a row, persisting past restarting the WebUI process/hard refresh browser.

1. Click generate/generate forever 
2. Wait for generation to be stuck at ~97%.
3. Either refresh the page with F5 or switch to another tab (img2img, PNGInfo, etc) and back.
4. Generation completes, image file is created at /output/ folder and am now able to start generating the next image.

### What should have happened?

Generations should not be stuck at 97% while the CLI has been at 100% for the past 10 minutes, when an image at identical settings usually takes 1 minute to output.

### Commit where the problem happens

98947d173e3f1667eba29c904f681047dea9de90

### What platforms do you use to access UI ?

Windows

### What browsers do you use to access the UI ?

Mozilla Firefox

### Command Line Arguments

```Shell
No command line arguments.
```


### Additional information, context and logs

_No response_
Repository: godot
Issue: Editor app beta version not set in macOS package info.plist
Labels: feature proposal,platform:macos,topic:buildsystem

### Godot version

v4.0.beta5.official [89a33d28f]

### System information

macOS 13.0.1

### Issue description

In macOS app bundles the application version used by macOS get info, picking the latest version of the app, crash reports etc is set in the info.plist file in the app bundle.  

There are two keys for this: CFBundleShortVersionString (usually used for the human readable displayed part, like "4.0.beta5") and CFBundleVersion (either used for a longer full version like "4.0.beta5.official [89a33d28f]" or just a build number "89a33d28f")

The possible bug is that currently they're both just set to 4.0 for the betas, so for example crash reports won't show what beta they are and you can't see which beta version the app is on macOS without launching it. The full version info to populate these fields obviously exists, but the fields are apparently not populated automatically in the current build process as they should. Or maybe they are, but the current script cuts away the useful .betaX part of the version string and which just leaves 4.0 as the version.

### Steps to reproduce

Inspect the Editor app bundle on macOS for one on the 4.0 betas

### Minimal reproduction project

Just download the macOS editor
Repository: godot
Issue: The `load()` function does not return the resource font if loaded from an absolute path
Labels: enhancement,documentation

### Godot version

4.0 Beta 4

### System information

Macbook Pro (M1)

### Issue description

I'm trying to use the `load()` function to pick a font in the fonts folder. But this returns a `null` object instead of the `resource`. The font does exist, but I could not find a way to load it from the absolute path.

### Steps to reproduce

1. Create a new project, add a new node, and add a script, on the `_ready` function use the following
2. `load("/absolute/path/to/font/file.tff")`
3. This will return a `null` object

### Minimal reproduction project

_No response_
Repository: flutter
Issue: Data synchronisation with multiple flutter engines
Labels: c: new feature,platform-android,engine,c: proposal,P3,team-android,triaged-android

We are integrating flutter into our existing application at the view level. We are using multiple flutter engines to load a particular type of view within a recycler view/collection view. This works perfectly fine. 
The issue is that a view loaded in one engine cannot access the data from a singleton class defined inside the flutter module. Lets say, I have a Singleton class created in the flutter module to manage the session. Now I have 2 flutter engines running and trying to access some data from the singleton class. This singleton class might have been updated either from native side or from API. The expectation here is that any view running over any engine should be able to access the updated data, but in practical its not. They always get the default/empty data.

Is there a way that the multiple engines can have access to a single data source? These multiple engines are created inside a FlutterEngineGroup. Is there anyway I can achieve this?
Repository: pytorch
Issue: Collective operations do not work with `torch.BoolTensor`s on `gloo` and raise `Invalid scalar type`
Labels: oncall: distributed

### 🐛 Describe the bug

Hi, collective operations do not work with `torch.BoolTensor`s on backend `gloo`. Actually `GENERATE_ALL_TYPES` macro in `torch/csrc/distributed/c10d/ProcessGroupGloo.cpp` seems to raise `RuntimeError: Invalid scalar type`.

To reproduce:
```python
import torch.distributed as dist

tensor = torch.empty((5,),dtype=torch.bool)
if dist.get_rank() == 0:
    gather_list = [torch.empty((5,),dtype=torch.bool) for _ in range(dist.get_world_size())]
else:
    gather_list = None
dist.gather(tensor, gather_list)
```
This is also the case for `all_gather`, `reduce`, `all_reduce` and `broadcast`. Changing `dtype=torch.bool` to `dtype=torch.uint8` resolves the error, while `torch.bool == torch.uint8` evaluates to `True`.

### Versions

PyTorch version: 1.13.0.dev20220927+cpu
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Jun 22 2022, 20:18:18)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-126-generic-x86_64-with-glibc2.29
Is CUDA available: False
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: GPU 0: GeForce 820M
Nvidia driver version: 340.108
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.991
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] pytorch-fid==0.1.1
[pip3] pytorch-ignite==0.4.10
[pip3] pytorch-sphinx-theme==0.0.24
[pip3] torch==1.13.0.dev20220927+cpu
[pip3] torch-model-archiver==0.6.0
[pip3] torch-tb-profiler==0.4.0
[pip3] torch-workflow-archiver==0.2.4
[pip3] torchaudio==0.13.0.dev20220923+cpu
[pip3] torchfile==0.1.0
[pip3] torchserve==0.6.0
[pip3] torchvision==0.14.0.dev20220926+cpu
[conda] Could not collect

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu