text:
Move SnapshotPurge to SyncAgentServer

This PR migrates and modifies the SnapshotPurge logic to the SyncAgentServer in order to allow for the SnapshotPurge to run as an asynchronous Task.
The only logic from the previous SnapshotPurge implementation that has been retained in the Task portion is the marking of system-generated Snapshots as Removed and the generation of the Leaves that represent the Snapshots that are to be removed. The Leaves are passed to separate calls to the SyncAgentServer for each individual Replica and will trigger the start of the actual SnapshotPurge process on each individual Replica.
The actual SnapshotPurge in the SyncAgentServer now runs as a goroutine and updates a PurgeStatus variable that represents the status of the SnapshotPurge. The user can use the purge-status subcommand of longhorn snapshot in order to check the status of the purge operation. The SyncAgentServer also tracks if there is currently a SnapshotPurge running, and will prevent multiple of these operations from attempting to run concurrently.
The integration tests used during the build for longhorn-engine have been modified accordingly in order to ensure that the Snapshot purge Task has completed before continuing.
This PR implements the longhorn-engine component of longhorn/longhorn#665 and should fix the race condition described in longhorn/longhorn#581.

Added additional Progress updates when running individual Snapshot operations.

Implemented --skip-if-in-progress flag.
Formatted longhorn snapshot purge-status output with indentation.
PurgeStatus now stores string from error during SnapshotPurge instead of the entire error.
Progress now calculates from additional sources such as number of Snapshots that are Removed and Progress of sfold.
sfold is now called by its method instead of by reexec.
The Error in PurgeStatus is now set as part of the defer in the goroutine of SnapshotPurge.
PurgeStatus now has a RWMutex for reading and writing data.
PurgeStatus has been reordered to be placed after RestoreInfo.
The Leaves of the SnapshotPurge operation are now calculated by the SyncAgentServer.
Rebased onto master.
Updated the vendor for sparse-tools to 19d6588be8e2e7d37a3b9dec9cd415e2f95cb41d.

Removed sfold registration from reexec in main.go.

progressChan has been removed from CoalesceTask. PurgeStatus has been modified to implement FoldFileOperations and contains additional information about the Snapshots being Removed in order to properly calculate the Progress.
CoalesceTask has been rewritten to contain the same basic doneChan implementation used in sparse-tools for use with the FileCoalesce and postIncrementalRestoreOperations methods.
The Progress calculation based on number of processed Operations has been removed.
The calculateProgress method has been removed.

Updated sparse-tools dependency. FoldFile is now a blocking call, and the logic will simply wait for FoldFile to finish instead of attempting to use channels to communicate the status of the operation.
CoalesceTask has been removed. CreateFileFoldOps can instead be used to create an implementation of FoldFileOperations from PurgeStatus.
FileCoalesce has been removed from the gRPC definition of SyncAgentServer.

Renamed removed to processed and toRemove to total.

Renamed CreateFileFoldOps to NewPurgeStatus.
Renamed ProcessStateCompleted to ProcessStateComplete.

LGTM.

authors: ttpcodes yasker

repo: longhorn/longhorn-engine


text:
[BUG]Fail to detach the volume when a node is down

Describe the bug
When a node is down, one replica in the volume becomes state error with the field replica.Status.instanceManagerName wrongly cleaned up. Then Longhorn cannot find out the replica manager and clean up the related instance for this error replica, which results in the volume getting stuck in detaching state.
Since there is no related log in the support bundle, we don't know why replica.Status.instanceManagerName is wrongly cleaned up here.
To Reproduce
Haven't found a way to reproduce it.
Expected behavior

The field replica.Status.instanceManagerName should not be cleared as long as the replica is not stopped
The volume on the down node can be detached.

Log
longhorn-manager-log:
2020-04-17T00:28:58.790892498Z time="2020-04-17T00:28:58Z" level=debug msg="Prepare to delete instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c"
2020-04-17T00:28:58.790925742Z time="2020-04-17T00:28:58Z" level=warning msg="Instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c is state error, error message: Instance Manager error"
2020-04-17T00:28:58.790978474Z time="2020-04-17T00:28:58Z" level=warning msg="Instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c crashed on Instance Manager instance-manager-r-b5776f64 at ip-10-100-104-246, try to get log"
2020-04-17T00:28:58.791039122Z time="2020-04-17T00:28:58Z" level=warning msg="cannot get crash log for instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c on Instance Manager instance-manager-r-b5776f64 at ip-10-100-104-246, error invalid Instance Manager instance-manager-r-b5776f64, state: unknown, IP: "
2020-04-17T00:28:58.791140776Z time="2020-04-17T00:28:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c\", UID:\"97544887-0c7d-44c2-b089-ae57fd51e407\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"3485845\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c"
2020-04-17T00:28:58.841217911Z time="2020-04-17T00:28:58Z" level=debug msg="Prepare to delete instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c"
2020-04-17T00:28:58.841273727Z time="2020-04-17T00:28:58Z" level=warning msg="Instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c is state error, error message: Instance Manager error"
2020-04-17T00:28:58.841334394Z time="2020-04-17T00:28:58Z" level=warning msg="Instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c crashed on Instance Manager instance-manager-r-b5776f64 at ip-10-100-104-246, try to get log"
2020-04-17T00:28:58.841376258Z time="2020-04-17T00:28:58Z" level=warning msg="cannot get crash log for instance pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c on Instance Manager instance-manager-r-b5776f64 at ip-10-100-104-246, error invalid Instance Manager instance-manager-r-b5776f64, state: unknown, IP: "
2020-04-17T00:28:58.841723401Z time="2020-04-17T00:28:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c\", UID:\"97544887-0c7d-44c2-b089-ae57fd51e407\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"3485845\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c"
2020-04-17T00:28:58.849292003Z time="2020-04-17T00:28:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"pvc-37278709-8841-459d-ac45-9e23165ad15e\", UID:\"b73f9073-adcf-4d92-83f3-52012740a4bd\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"3486017\", FieldPath:\"\"}): type: 'Normal' reason: 'Delete' Cleanup Volume Attachment on 'NotReady' Node: csi-25d66fad08068f1e21a39d3d036195a700816f9b162d7c04d40359987aad4e3f"
2020-04-17T00:29:23.223235016Z time="2020-04-17T00:29:23Z" level=info msg="Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"pvc-37278709-8841-459d-ac45-9e23165ad15e\", UID:\"b73f9073-adcf-4d92-83f3-52012740a4bd\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"3486017\", FieldPath:\"\"}): type: 'Normal' reason: 'Delete' Cleanup Volume Attachment on 'NotReady' Node: csi-25d66fad08068f1e21a39d3d036195a700816f9b162d7c04d40359987aad4e3f"

......

The replica info:
- typemeta:
    kind: Replica
    apiversion: longhorn.io/v1beta1
  objectmeta:
    name: pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c
    generatename: ""
    namespace: longhorn-system
    selflink: /apis/longhorn.io/v1beta1/namespaces/longhorn-system/replicas/pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c
    uid: 97544887-0c7d-44c2-b089-ae57fd51e407
    resourceversion: "3485845"
    generation: 5
    creationtimestamp: "2020-04-09T04:41:27Z"
    deletiontimestamp: null
    deletiongraceperiodseconds: null
    labels:
      longhornnode: ip-10-100-104-246
      longhornvolume: pvc-37278709-8841-459d-ac45-9e23165ad15e
    annotations: {}
    ownerreferences:
    - apiversion: longhorn.io/v1beta1
      kind: Volume
      name: pvc-37278709-8841-459d-ac45-9e23165ad15e
      uid: b73f9073-adcf-4d92-83f3-52012740a4bd
      controller: null
      blockownerdeletion: null
    initializers: null
    finalizers:
    - longhorn.io
    clustername: ""
    managedfields: []
  spec:
    instancespec:
      volumename: pvc-37278709-8841-459d-ac45-9e23165ad15e
      volumesize: 32212254720
      nodeid: ip-10-100-104-246
      engineimage: longhornio/longhorn-engine:v0.8.0
      desirestate: stopped
      logrequested: false
    enginename: pvc-37278709-8841-459d-ac45-9e23165ad15e-e-2a4d4869
    healthyat: "2020-04-09T04:41:40Z"
    failedat: ""
    diskid: 235508dad94866c6
    datapath: /var/lib/rancher/longhorn/replicas/pvc-37278709-8841-459d-ac45-9e23165ad15e-962945e3
    baseimage: ""
    active: true
  status:
    instancestatus:
      ownerid: ip-10-100-105-72
      instancemanagername: ""
      currentstate: error
      currentimage: ""
      ip: ""
      port: 0
      started: false
      logfetched: false

The corresponding instance manager info:
- typemeta:
    kind: InstanceManager
    apiversion: longhorn.io/v1beta1
  objectmeta:
    name: instance-manager-r-b5776f64
    generatename: ""
    namespace: longhorn-system
    selflink: /apis/longhorn.io/v1beta1/namespaces/longhorn-system/instancemanagers/instance-manager-r-b5776f64
    uid: 95301e97-fc07-44f2-a1f7-544390b5912f
    resourceversion: "3485835"
    generation: 1
    creationtimestamp: "2020-04-09T04:40:19Z"
    deletiontimestamp: null
    deletiongraceperiodseconds: null
    labels:
      longhorn.io/component: instance-manager
      longhorn.io/instance-manager-image: longhornio-longhorn-instance-manager-v1_20200301
      longhorn.io/instance-manager-type: replica
      longhorn.io/node: ip-10-100-104-246
    annotations: {}
    ownerreferences:
    - apiversion: longhorn.io/v1beta1
      kind: Node
      name: ip-10-100-104-246
      uid: 82d5641a-58d4-4cd1-9153-9da54821eb95
      controller: null
      blockownerdeletion: true
    initializers: null
    finalizers:
    - longhorn.io
    clustername: ""
    managedfields: []
  spec:
    image: longhornio/longhorn-instance-manager:v1_20200301
    nodeid: ip-10-100-104-246
    type: replica
    engineimage: ""
  status:
    ownerid: ip-10-100-105-72
    currentstate: unknown
    instances:
      pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c:
        spec:
          name: pvc-37278709-8841-459d-ac45-9e23165ad15e-r-ec0d4e6c
        status:
          endpoint: ""
          errormsg: Instance Manager error
          listen: ""
          portend: 10029
          portstart: 10015
          state: error
          type: ""
          resourceversion: 0
    ip: ""
    apiminversion: 0
    apiversion: 0

Environment:

Longhorn version: v0.8.0
Kubernetes version:
Node OS type and version:

We don't have a reliable way to reproduce this issue at the moment.

@dnoland1 Do you know if there is a way we can reproduce this? We've committed a fix for an obvious issue but unable to reproduce the issue before the fix.

@yasker I was able to reproduce this issue once after two tries. Used a two node k3s cluster with volumes of a replica of 2. I drained and remove 1st node. Terminated the VM and added a replacement VM. Once the new node's replicas were synced, I drained and removed the second k3s node, terminated the VM, added a replacement. In longhorn I could not remove the down node in the UI and volume was stuck in "Detaching..." state:

The test plan:

Deploy a cluster with 1 master node and 2 worker nodes (w1, w2). Deploy Longhorn v0.8.1.
Create a volume then attach it to node w2.
Use kubectl drain and kubectl delete node to remove node w1 first. Then power off the corresponding VM.
Add a new worker node w3 to the cluster.
Wait for the volume replica rebuild.
Remove the volume attached node w2. (Should we add a new worker node immediately here?)
The volume may get stuck in Detaching.

@dnoland1 Is the above test plan correct? And which Longhorn version were you using for the reproduce?

@dnoland1 can you help to reproduce it on v1.0.0-rc1 ? It's on branch v1.0.0 of longhorn/longhorn. You can use deploy/longhorn.yaml to deploy.

@shuo-wu I think that test plan should work. I used a 2 node k3s server setup with replica count of 2. For step 6, not sure if you need to immediately add a new worker, can wait a while, or if that's even needed. In my use case, replacement node was added within about 5 minutes. This was originally reproduced on longhorn 0.8.1.
@yasker I tried this on longhorn 1.0.0-rc1. I tried multiple times by cycling through 6 nodes total and could not reproduce the problem. As expected, the volume detached/attached fine and did not get stuck as it did with 0.8.1. The replica for the volume went into a failed state and the volume was degraded. Once the new node came online, it rebuilt a new replica and volume went back to healthy. These volumes were being used for cluster monitoring (prometheus/grafana) and during the swapping out of nodes, the volumes were not lost and I could view the full monitoring history.

@dnoland1 That's great news! We will see if we can write a test case to reproduce it. But that, we will need to add this test to our manual test plan https://github.com/longhorn/longhorn-tests/wiki/Manual-Test-Plan .

Pre-merged Checklist

[ ] Does the PR include the explanation for the fix or the feature?
[ ] Is the backend code merged?
[ ] Is the reproduce steps/test steps documented?
[ ] If the fix introduces the code for backward compatibility Has an separate issue been filed with the label release/obsolete-compatibility?
[ ] If labeled: area/ui Has the UI issue filed or ready to be merged?
[ ] if labeled: require-doc Has the necessary document PR submitted or merged?
[ ] If labeled: require-automation-e2e Has the end-to-end test plan been merged? Have QAs agreed on the automation test case?
[ ] if labeled: require-automation-engine Has the engine integration test been merged?
[ ] if labeled: require-manual-test-plan-doc Has the manual test plan been documented?

Reproduced the issue using longhorn 0.8.1

Deploy a 3 node k3s cluster - all nodes have control+worker nodes N1, N2, N3.
Deploy longhorn 0.8.1
Create a volume in longhorn, create a pv/pvc
Create a workload and use the volume created ^^^
The workload is attached to node N1
Force drain N1.
The volume is seen ind detaching state

Instance manager logs:
time="2020-05-22T23:51:51Z" level=warning msg="Instance test-r-5cbb037e is state error, error message: Instance Manager error"
time="2020-05-22T23:51:51Z" level=warning msg="Instance test-r-5cbb037e crashed on Instance Manager instance-manager-r-4c651163 at <ip>, try to get log"
time="2020-05-22T23:51:51Z" level=warning msg="cannot get crash log for instance test-r-5cbb037e on Instance Manager instance-manager-r-4c651163 at <ip>, error invalid Instance Manager instance-manager-r-4c651163, state: unknown, IP: 10.42.1.18"
time="2020-05-22T23:51:51Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"test-r-5cbb037e\", UID:\"45b80505-8f40-4d39-bcd0-246226b03d69\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"6805\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-r-5cbb037e"
time="2020-05-22T23:52:21Z" level=debug msg="Prepare to delete instance test-r-5cbb037e"
time="2020-05-22T23:52:21Z" level=warning msg="Instance test-r-5cbb037e is state error, error message: Instance Manager error"
time="2020-05-22T23:52:21Z" level=warning msg="Instance test-r-5cbb037e crashed on Instance Manager instance-manager-r-4c651163 at <ip>, try to get log"
time="2020-05-22T23:52:21Z" level=warning msg="cannot get crash log for instance test-r-5cbb037e on Instance Manager instance-manager-r-4c651163 at <ip>, error invalid Instance Manager instance-manager-r-4c651163, state: unknown, IP: 10.42.1.18"
time="2020-05-22T23:52:21Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"test-r-5cbb037e\", UID:\"45b80505-8f40-4d39-bcd0-246226b03d69\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"6805\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-r-5cbb037e"
time="2020-05-22T23:52:21Z" level=debug msg="Prepare to delete instance test-r-5cbb037e"
time="2020-05-22T23:52:21Z" level=warning msg="Instance test-r-5cbb037e is state error, error message: Instance Manager error"
time="2020-05-22T23:52:21Z" level=warning msg="Instance test-r-5cbb037e crashed on Instance Manager instance-manager-r-4c651163 at <ip>, try to get log"
time="2020-05-22T23:52:21Z" level=warning msg="cannot get crash log for instance test-r-5cbb037e on Instance Manager instance-manager-r-4c651163 at <ip>, error invalid Instance Manager instance-manager-r-4c651163, state: unknown, IP: 10.42.1.18"
time="2020-05-22T23:52:21Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"test-r-5cbb037e\", UID:\"45b80505-8f40-4d39-bcd0-246226b03d69\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"6805\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-r-5cbb037e"
time="2020-05-22T23:52:51Z" level=debug msg="Prepare to delete instance test-r-5cbb037e"
time="2020-05-22T23:52:51Z" level=warning msg="Instance test-r-5cbb037e is state error, error message: Instance Manager error"
time="2020-05-22T23:52:51Z" level=warning msg="Instance test-r-5cbb037e crashed on Instance Manager instance-manager-r-4c651163 at <ip>, try to get log"
time="2020-05-22T23:52:51Z" level=warning msg="cannot get crash log for instance test-r-5cbb037e on Instance Manager instance-manager-r-4c651163 at <ip>, error invalid Instance Manager instance-manager-r-4c651163, state: unknown, IP: 10.42.1.18"
time="2020-05-22T23:52:51Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"test-r-5cbb037e\", UID:\"45b80505-8f40-4d39-bcd0-246226b03d69\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"6805\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-r-5cbb037e"

Validated on longhorn 1.0.0-rc1
Steps:

Deploy a 3 node k3s cluster - all nodes have control+worker nodes N1, N2, N3.
Deploy longhorn 0.8.1
Create a volume in longhorn, create a pv/pvc
Create a workload and use the volume created ^^^
The workload is attached to node N1
Force drain N1.
Remove node from cluster
The volume is seen in detaching state
But the volume recovered. And is in healthy state
Volume is accessible

Longhorn-manager logs:
time="2020-05-23T00:15:17Z" level=warning msg="Instance test-e-5898de8d crashed on Instance Manager instance-manager-e-17bf11cd at <ip>, try to get log"
time="2020-05-23T00:15:17Z" level=info msg="Event(v1.ObjectReference{Kind:\"Engine\", Namespace:\"longhorn-system\", Name:\"test-e-5898de8d\", UID:\"cb7f68e0-c3a6-4cf1-bf25-7ded34edf5e9\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5344\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=error msg="failed to receive log for instance test-r-13d229d7: rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:17Z" level=warning msg="cannot get crash log for instance test-r-13d229d7 on Instance Manager instance-manager-r-b35fc103 at <ip>, error rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:17Z" level=error msg="failed to receive log for instance test-e-5898de8d: rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=warning msg="cannot get crash log for instance test-e-5898de8d on Instance Manager instance-manager-e-17bf11cd at <ip>, error rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=debug msg="Prepare to delete instance test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=warning msg="Instance test-e-5898de8d is state error, error message: Instance Manager error"
time="2020-05-23T00:15:17Z" level=warning msg="Instance test-e-5898de8d crashed on Instance Manager instance-manager-e-17bf11cd at <ip>, try to get log"
time="2020-05-23T00:15:17Z" level=info msg="Event(v1.ObjectReference{Kind:\"Engine\", Namespace:\"longhorn-system\", Name:\"test-e-5898de8d\", UID:\"cb7f68e0-c3a6-4cf1-bf25-7ded34edf5e9\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5344\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=error msg="failed to receive log for instance test-e-5898de8d: rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:17Z" level=warning msg="cannot get crash log for instance test-e-5898de8d on Instance Manager instance-manager-e-17bf11cd at <ip>, error rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=debug msg="Prepare to delete instance test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-r-13d229d7 is state error, error message: Instance Manager error"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-r-13d229d7 crashed on Instance Manager instance-manager-r-b35fc103 at <ip>, try to get log"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-e-5898de8d is state error, error message: Instance Manager error"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-e-5898de8d crashed on Instance Manager instance-manager-e-17bf11cd at <ip>, try to get log"
time="2020-05-23T00:15:47Z" level=info msg="Event(v1.ObjectReference{Kind:\"Engine\", Namespace:\"longhorn-system\", Name:\"test-e-5898de8d\", UID:\"cb7f68e0-c3a6-4cf1-bf25-7ded34edf5e9\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5344\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=error msg="failed to receive log for instance test-r-13d229d7: rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:47Z" level=warning msg="cannot get crash log for instance test-r-13d229d7 on Instance Manager instance-manager-r-b35fc103 at <ip>, error rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:47Z" level=error msg="failed to receive log for instance test-e-5898de8d: rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=warning msg="cannot get crash log for instance test-e-5898de8d on Instance Manager instance-manager-e-17bf11cd at <ip>, error rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-r-13d229d7 is state error, error message: Instance Manager error"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-r-13d229d7 crashed on Instance Manager instance-manager-r-b35fc103 at <ip>, try to get log"
time="2020-05-23T00:15:47Z" level=error msg="failed to receive log for instance test-r-13d229d7: rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:47Z" level=warning msg="cannot get crash log for instance test-r-13d229d7 on Instance Manager instance-manager-r-b35fc103 at <ip>, error rpc error: code = NotFound desc = cannot find process test-r-13d229d7"
time="2020-05-23T00:15:47Z" level=debug msg="Prepare to delete instance test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-e-5898de8d is state error, error message: Instance Manager error"
time="2020-05-23T00:15:47Z" level=warning msg="Instance test-e-5898de8d crashed on Instance Manager instance-manager-e-17bf11cd at <ip>, try to get log"
time="2020-05-23T00:15:47Z" level=info msg="Event(v1.ObjectReference{Kind:\"Engine\", Namespace:\"longhorn-system\", Name:\"test-e-5898de8d\", UID:\"cb7f68e0-c3a6-4cf1-bf25-7ded34edf5e9\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5344\", FieldPath:\"\"}): type: 'Normal' reason: 'Stop' Stops test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=error msg="failed to receive log for instance test-e-5898de8d: rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:47Z" level=warning msg="cannot get crash log for instance test-e-5898de8d on Instance Manager instance-manager-e-17bf11cd at <ip>, error rpc error: code = NotFound desc = cannot find process test-e-5898de8d"
time="2020-05-23T00:15:52Z" level=warning msg="Cannot find the instance status in instance manager instance-manager-r-b35fc103 for the running instance test-r-13d229d7, will mark the instance as state ERROR"
time="2020-05-23T00:15:53Z" level=debug msg="Instance handler updated instance test-e-5898de8d state, old state error, new state stopped"
time="2020-05-23T00:15:53Z" level=debug msg="Instance handler updated instance test-r-13d229d7 state, old state error, new state stopped"
time="2020-05-23T00:15:54Z" level=info msg="Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"test\", UID:\"02452570-35b0-48f8-9dc0-9fc5ae1d25df\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5129\", FieldPath:\"\"}): type: 'Normal' reason: 'Detached' volume test has been detached"
time="2020-05-23T00:16:05Z" level=debug msg="Prepare to create instance test-r-13d229d7"
time="2020-05-23T00:16:05Z" level=info msg="Event(v1.ObjectReference{Kind:\"Replica\", Namespace:\"longhorn-system\", Name:\"test-r-13d229d7\", UID:\"20df406b-fd76-4afe-9f7b-1aab2e21c1c0\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5715\", FieldPath:\"\"}): type: 'Normal' reason: 'Start' Starts test-r-13d229d7"
time="2020-05-23T00:16:06Z" level=debug msg="Instance test-r-13d229d7 starts running, IP 10.42.2.18"
time="2020-05-23T00:16:06Z" level=debug msg="Instance test-r-13d229d7 starts running, Port 10000"
time="2020-05-23T00:16:06Z" level=debug msg="Instance handler updated instance test-r-13d229d7 state, old state stopped, new state running"
time="2020-05-23T00:16:07Z" level=debug msg="Prepare to create instance test-e-5898de8d"
time="2020-05-23T00:16:07Z" level=info msg="Event(v1.ObjectReference{Kind:\"Engine\", Namespace:\"longhorn-system\", Name:\"test-e-5898de8d\", UID:\"cb7f68e0-c3a6-4cf1-bf25-7ded34edf5e9\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"5747\", FieldPath:\"\"}): type: 'Normal' reason: 'Start' Starts test-e-5898de8d"
time="2020-05-23T00:16:07Z" level=debug msg="Instance process test-e-5898de8d had been created, need to wait for instance manager update"

Was able to reproduce this issue on 0.8.1 using these steps also

Deploy a 3 node k3s cluster - all nodes have control+worker nodes N1, N2, N3.
Deploy longhorn 0.8.1
Create a 3-replica volume in longhorn, create a pv/pvc/pod. The volume is attached to N1.
Write some data to the volume and get the md5sum.
Force drain and remove N2, which contains one replica only.
Wait for the volume Degraded.
Force drain and remove N1, which is the node volume attached to.
Wait for the volume detaching then being recovered to healthy state.
Validate the volume content. (edited)

Validated successfully on 1.0.0-rc1
Validation: PASSED
Deploy a 3 node k3s cluster - all nodes have control+worker nodes N1, N2, N3.
2. Deploy longhorn 1.0.0-rc1
3. Create a 3-replica volume in longhorn, create a pv/pvc/pod. The volume is attached to N1.
4. Write some data to the volume and get the md5sum.
5. Force drain and remove N2, which contains one replica only.
6. Wait for the volume Degraded.
7. Force drain and remove N1, which is the node volume attached to.
8. Wait for the volume detaching then being recovered to healthy state.
9. Validate the volume content. (edited)

Now we can reproduce the issue, so we should be able to understand it better. E.g. what exactly went wrong, and what would triggered the issue. After we understand those, we can see if we need to automate the test case for it.

The cause of the reported case:

The attached node is drained then the engine/replica manager pod gets evicted.
The engine/replica becomes error. Then the field Status.InstanceManagerName will be unset immediately.
Longhorn receives the detach call from the CSI plugin and starts to detach the volume.
The node is removed and the instance map in the instance manager won't be updated automatically.
Since the field Status.InstanceManagerName is empty, the engine/replica controller cannot clean up the entry from the instance map. --> The engine/replica cannot become stopped.

One extra corner case:

The attached node is drained and the engine manager pod gets evicted.
The engine becomes state error then the auto reattachment logic is triggered.
The volume gets detached within a very short interval then starts reattaching. (It seems that the longhorn workloads haven't been cleaned up at this moment hence the detach would succeed?)
The node is removed and the attachment cannot succeed.
Longhorn receives the detach call from the CSI plugin and v.Spec.NodeID is unset.
But v.Status.CurrentNodeID is retained there. Hence the volume will get stuck in attaching state.
(One possible bug: If a volume somehow gets stuck in attaching state, will users be able to detach it manually? Need to double check it later)

Thanks @shuo-wu . For this issue, we are dealing with the original reported case only. The other corner case found by @shuo-wu will be dealt with in #1363.

source: gharchive/issue

repo: longhorn/longhorn

license_type: permissive

license_source: github-api


text:
[IMPROVEMENT] Improve manageability of share manager pod behaviors

Is your improvement request related to a feature? Please describe (👍 if you like this request)
The improvement is a subtask of https://github.com/longhorn/longhorn/issues/5658.
In the current implementation, the share manager pod is created and blindly mounts a volume regardless of its healthy state. The blind mounting behavior can lead to unexpected volume faulted if the volume is dead or orphaned caused by a power outage of node, network partition and so on. This ticket aims to share manager pod's behaviors more manageable and predictable.
With the improvement, the start flow will be as follows:

Share manager controller creates a share manager pod and bootstraps an NFS server without any filesystem exported
Share manager pod mounts the volume and exports it after receiving a FilesystemMount request
Share manager controller checks the mount status by FilesystemMountStatus. If the volume is mounted, transition the share manager state to "running"

Shutdown flow will be as follows:

Gracefully shut down the NFS server
Gracefully or forcefully unmount the volume
Tear down the device.

Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Will revisit the issue after introducing AD controller.

Hi @derekbit Will this volume mounting issue be resolve if we utilize the PV/PVC native mechanism of Kubernetes instead of developing the logic by ourselves? i.e., create a PV/PVC for share-manager pod and let Kubernetes handling the attach/mount logic?


text:
Bump csi-provisioner to v3.4.1

#5672

It looks like we need to update other sidecars as well (all of the versions we are using have fallen out of support). There are some interdependencies between versions that I want to be careful with (and it is probably best to handle all of it at once). I'll create a couple of new PRs tomorrow that handle this better. Apologies for the churn.

Besides of longhorn/longhorn repo, we need to update the version in longhorn/longhorn-manager as well: https://github.com/longhorn/longhorn-manager/blob/66e31ba3e7ae77779a9ba3b5bf6695e39b9f5f68/csi/deployment.go#L23-L28

Good catch, @PhanLe1010, and thanks for your comment. Unfortunately, I didn't look closely enough at how the driver was being deployed on my initial pass. I assumed the Helm chart was taking the provided values and doing the deployment of the driver (using a template or templates) directly. I see now that Helm instead deploys a longhorn-manager-deployer Pod that actually does the deployment (with the "longhorn-manager csi ..." command). Eventually, on uninstall, Helm deploys a longhorn-uninstall Pod (with the "longhorn-manager uninstall" command) that reverses it.
It's clear to me now why the additional values you pointed out exist. However, it's a bit unclear why the longhorn-manager executable itself must be responsible for creating and cleaning up the CSI components instead of the overarching deployment mechanism (e.g. Helm). Do you or @innobead have any insight to share on this? Do we support a workflow in which a user might directly execute longhorn-manager to install or uninstall CSI components? (This certainly isn't necessary for me to prepare a new PR, but it might help shape the way I think about proposed changes moving forward.)

Discussed with @ejweber: A few reasons that we are using longhorn-manager image in the driver-deployer to deploy the csi-xxx components instead of using the traditional Helm template are:

The driver-deployer can dynamically discover the kubelet directory and deploy the csi-xxx to connect to the correct the Unix domain socket
The driver watches the settings.longhorn.io like priorityClass, tolerations,... and sets them to csi-xxx deployment

source: gharchive/pull-request


text:
Java 7 compatibility

I am upgrading an application from Grails 2 to Grails 3 where your plugin is used.
We are currently required to run Java 7. From the looks of:
grails/buildtestdata/BuildTestDataGrailsPlugin : Unsupported major.minor version 52.0
your plugin was build with Java 8
Is it possible for you to build a Java 7 version of the plugin, to make it compliant with java 7 like Grails 3?

Yes, I didn't realize it was set to 1.8 compatibility. I have some other changes I will push out soon along with this change.

Fixed in 3.3.0

authors: longwa mlkristiansen

repo: longwa/build-test-data

license_source: bigquery


text:
consolidating the error handling mixins

There exists three mixin' which deal with form error handling. This ticket is to discovery and implement converting them into one single mixin'. Default model and collection error handling within Backbone should make this possible.

Documenting these mixins to contribute to the JSDoc issue #4 as well as to help solve this issue.

Mixins consolidated as much as possible into a generic errors handling hood to all ajax errors.

repo: lookout/gringotts

license: mit


text:
Question: Generating Slate doc using GraphQL

Is it possible to integrate GraphQL schema in Slate? Or to generate slate markdown from GraphQL schema?
https://graphql.org/

Maybe folks in the Spectrum community would have some more information? I'm not aware of any tools.

authors: lord raderio

repo: lord/slate


text:
Suggestion: AssemblyInfo task support for metadata

First, thank you for the excellent library. We're using the AssemblyInfo support task to generate versioned assemblies at build time based on the build environment version, specifically VSTS build numbers. It has been extremely helpful! We hit a possible use case for metadata, and we wanted to throw it out there.
For reference, the AssmblyInfo task is here:
https://github.com/loresoft/msbuildtasks/blob/master/Source/MSBuild.Community.Tasks/AssemblyInfo.cs
We're trying to expose the source control commit hash to our runtime environment, so that we can display the information in a 'debug' screen. We use this for tractability, the hash helps us identify "what exact state of code drove the version you have in your hand".
We are thinking of using the AssemblyMetadataAttribute to pass the information along, as described here:
https://msdn.microsoft.com/en-us/library/system.reflection.assemblymetadataattribute(v=vs.110).aspx
This would be easily extracted in the run-time code.
We looked at the AssemblyInfo class and did not find an option to set or pass assembly metadata along to the generated AssemblyInfo file.
It would be helpful for us to be able to do so, ideally passing key value pairs in a property, as in this example: http://stackoverflow.com/questions/24176028/parse-key-value-pairs-from-msbuild-property
Use case:
I would plan to set up an overrideable property to capture the values at the MSBuild flags line, for example:
/p:fooKey=fooValue;barKey=barValue

Each pair would output assembly metadata like (C# example):
[assembly: AssemblyMetadata("fooKey","fooValue")]
[assembly: AssemblyMetadata("barKey","barValue")]

into the AssemblyInfo.cs
In the code these values would be extracted into a dictionary for use:
static void Main(string[] args)
{
	// get metadata from the assembly and convert to a dictionary
	var assembly = Assembly.GetEntryAssembly();
	var metadataAttributes = assembly.GetCustomAttributes(typeof(AssemblyMetadataAttribute), true);
	var metadata = metadataAttributes.OfType<AssemblyMetadataAttribute>().ToDictionary(a => a.Key, a => a.Value);

	// extract a value and print it
	var valueForFooKey = metadata["fooKey"];
	Console.WriteLine(valueForFooKey);

	// print keys
	foreach (var key in metadata)
	{
		Console.WriteLine(key);
	}
}

Using this system we could easily expose the commit hash, source and build URLs and other build system environment variables to our running client code.
Thanks much, and I appreciate any consideration or further thoughts!

I'm looking into possibly implementing this.
I've found that using itemGroups may be an effective way to pass pairs.
On the command line, this syntax should work:
/p:bazMetaVars="fooKey=fooValue;barKey=barValue"
According to:
http://stackoverflow.com/questions/11794756/how-to-pass-variable-number-of-items-in-propertygroup-itemgroup-to-msbuild-scrip
The item group can then be passed in to the task as shown here:
http://stackoverflow.com/questions/7820802/msbuild-passing-array-to-a-custom-task
From there it's C# code to do checks and split each pair, as well as setting up the attributes.

As a follow up, my temporary work-around is to add metadata entries directly.
A property for an entry might look like this:
<AssemblyMetadata>[assembly: System.Reflection.AssemblyMetadata("Configuration|Platform", "$(Configuration)|$(Platform)")]</AssemblyMetadata>
We have a value for the file that looks like this:
<AssemblyInfoTargetFile>$(MSBuildProjectDirectory)\Properties\AssemblyInfo.$(AutoversionAssemblyInfoExtension)</AssemblyInfoTargetFile>
Then our assembly info and extra metadata end up like this (with property values for each part):
<AssemblyInfo
CodeLanguage="$(AutoversionAssemblyCodeLanguage)"
OutputFile="$(AssemblyInfoTargetFile)"
AssemblyTitle="$(AutoversionAssemblyTitle)"
AssemblyDescription="$(AutoversionAssemblyDescription)"
AssemblyConfiguration=""
AssemblyCompany="$(AutoversionAssemblyCompany)"
AssemblyProduct="$(AutoversionAssemblyProduct)"
AssemblyCopyright="$(AutoversionAssemblyCopyright)"
AssemblyTrademark=""
CLSCompliant="false"
AssemblyVersion="$(BuildVersion)"
AssemblyInformationalVersion="$(AutoversionAssemblyInformationalVersion)"
AssemblyFileVersion="$(BuildVersion)" />

<!-- for now, we will append literal lines to the file. -->
<WriteLinesToFile File="$(AssemblyInfoTargetFile)" Lines="$(AssemblyMetadata)" Overwrite="false" />

repo: loresoft/msbuildtasks


text:
Reduce allocations for String#classify method

I used stackprof gem and this code:
  100_000.times { Lotus::Utils::String.new('lotus_utils/test').classify }

Before
==================================
  Mode: object(1)
  Samples: 3500005 (0.00% miss rate)
  GC: 0 (0.00%)
==================================
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
   3300005  (94.3%)     1600004  (45.7%)     Lotus::Utils::String#classify
    900000  (25.7%)      900000  (25.7%)     Lotus::Utils::String#method_missing
    800001  (22.9%)      800001  (22.9%)     Lotus::Utils::String#split

After
==================================
  Mode: object(1)
  Samples: 3000005 (0.00% miss rate)
  GC: 0 (0.00%)
==================================
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
   2800005  (93.3%)     1100004  (36.7%)     Lotus::Utils::String#classify
    900000  (30.0%)      900000  (30.0%)     Lotus::Utils::String#scan
    800001  (26.7%)      800001  (26.7%)     Lotus::Utils::String#split

:tada:

@davydovanton Thank you very much, this is the kind of contributions that I really :heart:

thanks for merge, @jodosha :star2:

authors: davydovanton jodosha

repo: lotus/utils


text:
Enables playback progress on Android Auto list items

With this change, the playback progress can be added to the MediaItem. If specified, the value should be between "0.0" and "1.0". A value of 0 sets the status not played, a value above 0.98 sets the status fully played. For values in between, the status partially played is set, which is indicated by a status bar.
https://developer.android.com/training/cars/media#metadata-indicators

It would be great if we could also update the progress while playing. But I'm afraid the changes needed for this have to be made in KotlinAudio. See https://developer.android.com/training/cars/media#browse-progress-bar

I'll fiddle with KA later this week, auto update progress would be great

tried this but couldnt see updates:( and playing the mediaitem twice breaks the mediasession
https://github.com/lovegaoshi/react-native-track-player/commit/cdd3118c44cbc4ca96d7ec06cfbf8690e24d46b6
id try uamp media3 when i get some time
dunno if flutter actually has this working too
https://github.com/ryanheise/audio_service/blob/ed856d6a074ff6d4a9d9681b0a13993c1f51f4e8/audio_service/android/src/main/java/com/ryanheise/audioservice/AudioService.java#L561

I tried setting the mediaId of the current playing track in the KA BaseAudioPlayer. This works in the meaning that no errors occur. but unfortunately it has no effect on the progress bar.

authors: lovegaoshi schoetty

repo: lovegaoshi/react-native-track-player


text:
sharp toFile with callback is not working

What is the output of running npx envinfo --binaries --languages --system --utilities?
What are the steps to reproduce?
What is the expected behaviour?
Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?
Are you able to provide a sample image that helps explain the problem?

?

authors: eldhoseelias lovell

repo: lovell/sharp


text:
Termux, binaries are not yet available for android-arm64v8

after running npm install sharp in termux . i found below error
sharp: Installation error: Prebuilt libvips 8.14.5 binaries are not yet available for android-arm64v8
i am not able to run npm install
please help

For Termux, please see https://github.com/lovell/sharp/issues/1889#issuecomment-535840238

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


text:
Stream metadata and resize

Hello,
I'm currently working with Sharp version 0.32.4 to obtain image sizes and subsequently resize them to 50% of their original dimensions using the resize function.
Here's a snippet of my code:
const transformer = sharp();
thumbnail.pipe(transformer);
const { width, height } = await transformer.metadata();
logger.info("Original width and height:", width, height);
const newWidth = width / 2;
const newHeight = height / 2;
const chain1 = transformer.resize(newWidth, newHeight)
                          .toFormat(config.imageThumbnail.format);
receivedFile.push({
  id,
  type: "thumbnail",
  name: thumbName,
  stream: chain1
});

This code performs well with very smallimages (around 20 KB), but I encounter issues when processing larger images.
Specifically, the process seems to hang at the metadata function call, as indicated by the absence of the log print statement that follows it.
Could someone guide me on how to correctly handle images resize base on image metadata or suggest any adjustments to my current approach?
Thank you!

Perhaps try transforming via https://www.npmjs.com/package/peek-readable so you can "peek" at the first N bytes and check it for metadata e.g. https://github.com/lovell/sharp/issues/2225#issuecomment-847248142

I hope this information helped. Please feel free to re-open with more details if further assistance is required.

authors: lovell shmueldarchi


text:
How is it open source if there is no training data set ?

For science  👨🔬 👩🔬

Oh sure, looks like you are interested in a couple of hundred dick pics! If so, I'll gladly send you the training set. 😈😜

hate you guys' work!

Hey, seems like a lot of people are really interested in the dataset.
I am trying to figure out a way to share the dataset without getting into any legal issues :)

Hi! I've just started doing research in this area recently, have you shared the dataset yet?

authors: GarrickLin absolute-heike genghisun onmyway133

repo: lovoo/NSFWDetector


text:
[cosim] Fixup ebreak behaviour

When DCSR is set such that ebreak will enter debug mode we were getting cosim mismatches. This was because Ibex produces the ebreak on the RVFI interface and spike effectively skips right over it and executes the first instruction of the debug handler immediately. Traps have similar but not identical behaviour so we need a special case in the step function to handle this.

This is interesting, I have been using the DCSR.ebreakm/u functionality in the hardware_breakpoints test/PR and have not seen and co simulation mismatches there. It's possible that test only makes use of one of m/u modes and not the other, so it could be that I guess. I haven't thought about it too much.

This is interesting, I have been using the DCSR.ebreakm/u functionality in the hardware_breakpoints test/PR and have not seen any cosimulation mismatches there. It's possible that PR only makes use of one of m/u modes and not the other, so it could be that I guess. I haven't thought about it too much.

Yeah this will only come up if you set the relevant DCSR bit to turn the ebreak into a break into debug rather than causing a breakpoint exception. I think the ebreakmu is the only test which does that.

I think the ebreakmu is the only test which does that.

So I also use that behaviour in the hardware_breakpoints test / PR, which uses ebreaks to get into debug mode to then change the trigger address. Right at the start of the test it sets the DCSR.ebreakm/u bits = 1. So I believe I'm exercising the same behaviour?

I think the ebreakmu is the only test which does that.

So I also use that behaviour in the hardware_breakpoints test / PR, which uses ebreaks to get into debug mode to then change the trigger address. Right at the start of the test it sets the DCSR.ebreakm/u bits = 1. So I believe I'm exercising the same behaviour.

Ah ok.
May also be a behaviour that altered with the recent ebreak change in Spike (https://github.com/lowRISC/riscv-isa-sim/pull/22)

authors: GregAC hcallahan-lowrisc

repo: lowRISC/ibex


text:
Move GlobalMock to a more universal location

Currently, GlobalMock<T> exists under sw/device/silicon_creator, however it is a useful class for testing in other parts of the codebase.
Move/refactor GlobalMock into a more universal location.

@timothytrippel Anything left to do here?

Looks like it is sw/device/lib/base/ now.

authors: cfrantz msfschaffner timothytrippel

repo: lowRISC/opentitan


text:
[ibex] Do not vendor in duplicated top_pkg into OT

top_pkg is a global package and may appear only once in the tree. Before
this change, there were two instances of this package: one in opentitan,
and one vendored in through Ibex.
Remove the one from Ibex when vendoring in.

Yes, however, I'm not sure how whole-chip regressions will be run in the end. There might be the need to have some Ibex DV available in OT as well.
Beyond that, we need to invest in a bit of warning/error infrastructure in FuseSoC to make sure we catch such duplicates early. I filed https://github.com/lowRISC/opentitan/issues/2512 for that.

And filed https://github.com/lowRISC/opentitan/issues/2513 to potentially stop vendoring the DV part.


text:
[otp_ctrl] Add random default value mechanism for secret OTP partitions

This came out of this comment: https://github.com/lowRISC/opentitan/pull/4464#discussion_r542958237
It basically adds the option to declare a randomized default value for specific items stored within OTP.
The mechanism is similar to the RndCnst mechanism on the top-level.
I.e. randomization is performed when calling the translate-otp-mmap.py script and is based on a seed for repeatability.
If we decide later on that the OTP memory map generation script should be called by topgen, we can choose to derive that seed from the global seed used for the RndCnst on the top-level.

Rebased onto latest changes on master.


text:
Always responding with 401 Unauthorized

I have a simple Flask app set up and tested using Twilio + ngrok locally. When I flip testing off, the endpoint always responds with a 401 Unauthorized to Twilio.
I have SECRET_KEY set to some random string, TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN correctly set (because I can make requests to the Twilio API), but it seems like the authorization wrapper in this library is doing something weird.
It looks like the wrapper is checking for authorization headers, with the username twilio and some password. What should the password be?
Assuming it can just be anything (as long as the username is twilio), I tried setting my webhook to https://twilio:abcdefg@abcxyz.herokuapp.com/webhooks/sms.xml. I can see Twilio making two requests (like the docs say, but the second request is still 401 Unauthorized.
What am I missing?

The package initiates the call using a password that is a random string, signed with itsdangerous. How long are you waiting from the time that you generate the twiml document and the time that you make the call? The signature is only valid for 10 minutes. (That timeout should probably be a configuration variable.)

I'm not using the library to make a call, I'm using it to handle SMS webhooks. I have the flask endpoint's URL in the Twilio configuration panel as the webhooks to send to when a new SMS is received.

@pranjut No, I never solved this. I ended up switching to stuff built up from Twimlets.

Thank @iandees

authors: iandees lpsinger pranjut

repo: lpsinger/flask-twilio


text:
Can you make a build for the latest release (0.62.1)

:)

Sorry about that.
docker pull lroguet-rpi-home-assistant:0.62.1 should work now.

repo: lroguet/rpi-home-assistant

license: MIT


text:
Programming exercises: Fix bug where the tooltips on the timeline when creating a programming exercise weren't displayed correctly

Checklist
General

[x] I tested all changes and their related features with all corresponding user types on a test server.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I added multiple screenshots/screencasts of my UI changes.

Motivation and Context

The tooltips for the Timeline when creating a new Programming Exercise were sometimes displayed to the bottom and sometimes to the top. Also the text was only shown partially.
Description

I fixed the issue https://github.com/ls1intum/Artemis/issues/5125.
Steps for Testing

Prerequisites:

1 Course

Go to course
Click "Generate new Programming Exercise"
Scroll to Timeline
Check if the tooltips are now displayed correctly
Verify, that no other tooltip is broken now

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[x] Test 1
[ ] Test 2

Test Coverage

unchanged
Screenshots

Tested on TS1. Works as expected.
Congrats for your very first PR :D
One thing maybe: the tooltip for "Release Date" and "Due Date" are both missing a dot at the end. Is it possible to add this in this commit as well?
Another thing, but this might be too much for this commit: change the background color of the tooltip to the grey color we use for the input in points, bonus points and submission policy. Right now the tooltip does not standout very much. Or even better: just leave the background color as is, but add a thin white border to it.

Thank you!
I added the dots for the mentioned tooltip texts.
I think editing the background color of the tooltips is out of the scope of this Issue as it will also affect all the other tooltips in the application. But I will add a new Issue for this.

Tested on TS1, works as expected.
Just a small note: In the German version, all tooltips except "Veröffentlichungsdatum der Beispiellösung" are also missing the dot at the end. Personally, I would also leave out the brackets at the second sentence of "Automatische Tests", because I think it looks better. But that's just my opinion :)

I added the missing dots in the german texts.

The rightmost tooltip still overflows the browser window.

I fixed it.


text:
Development: Refactor import components

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[x] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Motivation and Context
Reduce code duplication.

Description

Made the PagingService generic, all subclases now implement the common search() method.
Used a bride pattern to like the import components with their respective paging service
Removded dupliacted client tests

With these changes, the lecture import component goes from 165 lines to this cute little component:

Steps for Testing
Check that all import components still work correctly.

Import exercises into a course / into an exam
Import exams and exercise groups
Import Lectures
Import Competencies and Prerequisites
Import SCA configurations into an programming exercise (on the PE grading page)
Import Submissions as example submissions

Verify that for all import components:

Sorting works
Highlighting works
Importing works (obviously)

Testserver States

[!NOTE]
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked

Review Progress
Performance Review

[ ] I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance

Code Review

[x] Code Review 1
[ ] Code Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Summary by CodeRabbit

Summary by CodeRabbit

New Features

Implemented a new import functionality across various components with simplified search and sorting capabilities.
Enhanced paging services to support more specific types and search options.

Bug Fixes

Fixed table headers to use static strings for consistent sorting behavior.

Refactor

Streamlined components by extending from a common ImportComponent.
Updated paging services to use generic types for improved code reusability.

Style

Adjusted UI elements to match the updated sorting and searching features.

Tests

Updated unit tests to reflect changes in component and service functionalities.
Added new tests for the ImportComponent and related services.

Documentation

Release notes updated to inform users about the new import experience and interface improvements.

I just noticed that the code coverage is still missing, please add it so we can be sure that the coverage is still good (since you refactored the tests aswell 😄)

authors: Strohgelaender rstief


text:
Add SwiftLint action file

Note: It's okay for the SwiftLint action to fail for now. It will succeed once #151 is merged

The gh action from norio-nomura is quite old. Can we use this fork instead: https://github.com/sinoru/actions-swiftlint


text:
[Feature request] Add a block for creation date

os: macOS 13.2.1
lsd --version: 0.23.1
echo $TERM: xterm-256color
echo $LS_COLORS:

Feature request / Proposition
First of all, thanks for this cool tool, it already is really good 👍
Congrats on the speed, it is really blazing fast 👏
And the output is amazing in terms of readability 😍
If I got it well, the date block displays the modification date.
I suggest having two possible date blocks: creation date and modification date.
This is feature is present in exa and I find it quite useful.
Please tell me what you think, and feel free to close if you don't think this is relevant.

the newer version in GNU ls also support showing the creation date, it should be good if we can have it

/kind feature

/kind feature

authors: ThomasHezard zwpaper

repo: lsd-rs/lsd


text:
Runner window position

Is it possible to make runner window to dock at the bottom rather then at the side?
Thank you.

It is possible to do this with a change to atom-runner. I would accept a patch that implemented this as an option toggle.
For what it's worth, the line in question is here. You would just need to change that to splitDown. You could go into your packages directory and make this change locally if you were interested.

Actually I just added this in 2.6.0, it was an easy change. You should be able to toggle this in the plugin settings now.

authors: esledov lsegal

repo: lsegal/atom-runner


text:
Open files before editing

It is useful to open files before edit them. It will enable an undo option.
todo

[x] Xaml files are not opened event the checkbox is set.

Fixed in a draft. No bugs known at now. Closed.

repo: lsoft/AdjustNamespace


text:
🛑 Mirror-爬 is down

In 3023925, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1879 ms

Resolved: Mirror-鱼露 is back up in 2fb05d5.


text:
🛑 Mirror-爬 is down

In fdc5642, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 984 ms

Resolved: Mirror-鱼露 is back up in 325b422.


text:
🛑 Mirror-爬 is down

In 5c013c1, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1024 ms

Resolved: Mirror-鱼露 is back up in 6287394.


text:
🛑 Mirror-爬 is down

In e4689ea, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 969 ms

Resolved: Mirror-鱼露 is back up in ac82eef.


text:
🛑 Mirror-爬 is down

In 1b968d8, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 785 ms

Resolved: Mirror-鱼露 is back up in f624c01.


text:
🛑 Mirror-爬 is down

In 4db235a, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 851 ms

Resolved: Mirror-鱼露 is back up in 4de3351.


text:
🛑 Mirror-爬 is down

In abfc283, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 952 ms

Resolved: Mirror-鱼露 is back up in de1b8e3.


text:
🛑 Mirror-爬 is down

In d50295b, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 735 ms

Resolved: Mirror-鱼露 is back up in 90bdefb.


text:
🛑 Mirror-爬 is down

In abf379f, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 857 ms

Resolved: Mirror-鱼露 is back up in d6cf57e.


text:
🛑 Mirror-爬 is down

In 984388b, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1319 ms

Resolved: Mirror-鱼露 is back up in e070ba9.


text:
🛑 Mirror-爬 is down

In 91daed5, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 931 ms

Resolved: Mirror-鱼露 is back up in ce5f3e1.


text:
BIP39 seed phrase

Support BIP39 for generating private keys.
For ECDSA, BIP39 should be the only method available for seeding.
For ED25519, the current schema should remain the default. BIP39 should be an alternative.
This should later be supported by all LTO client libraries

Split out in #43 and #44

repo: ltonetwork/seasalt


text:
#10 Issue - Validate Email Address

WHEN I enter text into the email address field
THEN I receive a notification if I have entered an invalid email address


text:
nanosleep() implicitly converts floats to zeroes

i.e.
nanosleep({tv_sec=2.1, tv_nsec=10.1})

is executed as
nanosleep({tv_sec=0, tv_nsec=0})

whereas I expect
nanosleep({tv_sec=2, tv_nsec=10})

ping

nanosleep needs a  PosixTimespec argument  that seems to be defined with only integer values.
You can make a wrapper to fix your wrong values
local function PosixTimespecFix(t)
  t.tv_sec=math.floor(t.tv_sec)
  t.tv_nsec=math.floor(t.tv_nsec)
  return t
end

and use
nanosleep(PosixTimespecFix({tv_sec=2.1, tv_nsec=10.1}))

yes, I understand and have done exactly this workaround. But problem still exists.

The problem in the handling of numbers inside the binding.

repo: luaposix/luaposix


text:
Fix the Travis CI status badge URL

Does what it says on the box: the badge is green now.
Additionally, all the links that were pointing to the old  iponweb/luavela repo were updated with luavela/luavela.

@igormunkin - well you can merge it, can't you?

@eliasdaler, it seems either I don't have the proper grants or maybe the new github interface is too complicated for me -- anyway, I failed to find the green button.
Nevertheless, I guess our rule for two LGTMs still stands, doesn't it?
Summon @igelhaus for the help.

Thanks for help guys! I was quite busy at work :-(

authors: igelhaus igormunkin keeprocking

repo: luavela/luavela


text:
Fix bug in ZstdBufferDecompressingStream when array backing ByteBuffer is shared

Motivation
The current implementation of ZstdBufferDecompressingStream fails with com.github.luben.zstd.ZstdIOException: Unknown frame descriptor when the interface is used with a ByteBuffer which is backed by an array which is shared with other ByteBuffers. This is a bug in the implementation where we assume that the ByteBuffer represents the view of the entire backing array.
Change
Change the implementation to specifically use the array represented by the bytebuffer view instead of the entire backing array.
Testing
Added a test case which fails prior to the change and passes after it.

LGTM

What was the impact to OpenSearch users due to this bug?  Would they sometimes hit this exception, under specific circumstances?  Always hit it?  During indexing (maybe merging, which might decompress stored fields) or searching (when also retrieving stored fields)?

authors: divijvaidya luben mikemccand

repo: luben/zstd-jni


text:
An item with the same key has already been added

@michaeldimoudis got this exception at the first start with 2.1.1. It never occurred afterwards.
2016-06-04 12:38:12.362 ContinuousFeedbackiOS[97190:6563997] Warning: Unhandled exception: System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException (ExceptionResource resource) [0x00000] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/throwhelper.cs:72
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Insert (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value, Boolean add) [0x0008e] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/collections/generic/dictionary.cs:336
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value) [0x00000] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/collections/generic/dictionary.cs:192
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x000ab] in <filename unknown>:0
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:143
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x002bc] in <filename unknown>:0
  --- End of inner exception stack trace ---
---> (Inner Exception #0) System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException (ExceptionResource resource) [0x00000] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/throwhelper.cs:72
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Insert (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value, Boolean add) [0x0008e] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/collections/generic/dictionary.cs:336
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value) [0x00000] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/collections/generic/dictionary.cs:192
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x000ab] in <filename unknown>:0
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/data/lanes/2922/7b89851d/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:143
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x002bc] in <filename unknown>:0 <---

I see the fix, when should we expect a merge and nuget package ?

Should be soon. If you need to fix it ASAP you can use nugets from our AppVeyor page,  where nugets are build for every commit.

@daniel-luberda  Great, can I get a link ?

It's on project page (just click Build badge)  https://ci.appveyor.com/project/molinch/ffimageloading/build/artifacts

Nuget with fix released (2.1.2)

authors: NVentimiglia daniel-luberda molinch

repo: luberda-molinet/FFImageLoading


text:
🛑 Školský šport is down

In bf26ba6, Školský šport (https://skolskysport.sk/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Školský šport is back up in 9fc5dd9.

repo: lubosm/minedusk-uptime


text:
fix calculation of the length of appended STREAM frames

For the last STREAM frame we omit the Length field. When packing STREAM frames, we need to account for this byte saving when calculating the length of the payload.

Codecov Report

Merging #2047 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2047      +/-   ##
==========================================
+ Coverage   85.62%   85.62%   +0.01%
==========================================
  Files          99       99
  Lines        7175     7178       +3
==========================================
+ Hits         6143     6146       +3
  Misses        753      753
  Partials      279      279

Impacted Files
Coverage Δ

framer.go
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io marten-seemann

repo: lucas-clemente/quic-go


text:
Update Z3_MathAutoCorrect.bas & UpdateChartSeries.bas

Addition of keys of the math autocorrect mapping dictionary

Update UpdateChartSeries.bas
Update to let user to choose to update all charts or only selected chart in the active sheet.
Added functionality to update chart reference to other sheets optionally


text:
DST crashes when starting with NucleousCoop

Hi there! I am trying to run Don't Starve Together (DST) with 2 controllers. Once I get them recognized by NucleousCoop and start the game, it crashes before starting.
Here is the log generated:
[Header]

Saturday, June 6, 2020

1:30:29 PM

Nucleus Coop Alpha v8

[Message]

Process has exited, so the requested information is not available.

[Stacktrace]

at System.Diagnostics.Process.EnsureState(State state)

at System.Diagnostics.Process.get_MainWindowHandle()

at Nucleus.Gaming.GenericGameHandler.Play()

at Nucleus.Gaming.GameManager.play(Object state)

How can I fix this? Would really like to play DST with my friends!

Hi, did you follow this guide? https://www.reddit.com/r/localmultiplayergames/comments/axxpb9/dont_starve_together_4_player_splitscreen_on_pc/
If so, please report the issue either on reddit, or in our discord for a quicker and better response

Yes, I followed. The game crashes right when I press 'Play' on NucleousCoop
I have also posted my issue on Reddit but got no comments:
https://www.reddit.com/r/nucleuscoop/comments/gxq6fj/nucleouscoop_crashes_when_starting_dont_starve/

Hmm, in that case I'd try in the discord, usually the best place for technical support.
https://discord.gg/ZaRb3e

@Snailedlt can you send me the invite to discord again please? the link is no longer valid. thanks

https://discord.gg/KFPkgtb

authors: JoaoLages Snailedlt

repo: lucasassislar/nucleuscoop


text:
Missing GetOrdersStatus feature

I've inspected the source code and realize that there is no way to get the statuses of a list of orders. Such operation is documented at https://www.clearsale.com.br/integracaov2/service.asmx?op=GetOrdersStatus. Have you plan to add such feature soon?

Unfortunately, I don't have plans to add this feature soon.
Would you like to contribute with the library? Just send me a PR.

repo: lucasmro/ClearSale


text:
Add candy-cane/lollipop/popsicle/dessert/popcorn icons

Related to #1289, and #1306.
Alts:

cake-slice alts:

I think pudding looks generic enough to warrant a primary name like dessert, just so that we cater to a more international audience for whom pudding might not mean the same thing. 😉

The desert icon is fantastic.

Nice icons @danielbayley !!

authors: danielbayley ericfennis jguddas karsa-mistmere

repo: lucide-icons/lucide

license: ISC


text:
Trying to pretrain with longer max sequence length

I've tried to extend your electra openwebtext examples by using your pre-process script with appropriate arguments for max sequence length of 768, as follows:
export PYTHONPATH=.
python pretraining/openwebtext/preprocess.py \
--max-seq-length 768 \
--trg-dir data/openwebtext_features_768 \
--n-dataset-building-processes 8

I then have custom json files for the electra generator and discriminator with the following change from the small_generator.json and small_discriminator.json:
"embedding_size": 768,
When I try to do pretraining with the new tokenization and the changed specification I get what looks like a dimension mismatch during training. I have been careful to pass the modified data folder with the new, longer feature tensors.

@DarrenAbramson Thanks for submitting the issue! Could you also paste the specific error trace that you encountered?

2020-09-21 14:18:05,966 : PyTorch version 1.6.0 available.
2020-09-21 14:22:54,700 : TensorFlow version 2.0.0 available.
2020-09-21 14:23:55,160 : loading configuration file pretraining/openwebtext/medium_generator.json
2020-09-21 14:23:55,162 : Model config ElectraConfig {
  "architectures": [
    "ElectraForMaskedLM"
  ],
  "attention_probs_dropout_prob": 0.1,
  "embedding_size": 768,
  "hidden_act": "gelu",
  "hidden_dropout_prob": 0.1,
  "hidden_size": 192,
  "initializer_range": 0.02,
  "intermediate_size": 768,
  "layer_norm_eps": 1e-12,
  "max_position_embeddings": 768,
  "model_type": "electra",
  "num_attention_heads": 3,
  "num_hidden_layers": 12,
  "pad_token_id": 0,
  "summary_activation": "gelu",
  "summary_last_dropout": 0.1,
  "summary_type": "first",
  "summary_use_proj": true,
  "type_vocab_size": 2,
  "vocab_size": 30522
}

2020-09-21 14:23:56,924 : loading configuration file pretraining/openwebtext/medium_discriminator.json
2020-09-21 14:23:56,925 : Model config ElectraConfig {
  "architectures": [
    "ElectraForPreTraining"
  ],
  "attention_probs_dropout_prob": 0.1,
  "embedding_size": 768,
  "hidden_act": "gelu",
  "hidden_dropout_prob": 0.1,
  "hidden_size": 768,
  "initializer_range": 0.02,
  "intermediate_size": 3072,
  "layer_norm_eps": 1e-12,
  "max_position_embeddings": 512,
  "model_type": "electra",
  "num_attention_heads": 12,
  "num_hidden_layers": 12,
  "pad_token_id": 0,
  "summary_activation": "gelu",
  "summary_last_dropout": 0.1,
  "summary_type": "first",
  "summary_use_proj": true,
  "type_vocab_size": 2,
  "vocab_size": 30522
}

/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [32,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [33,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [34,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [35,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [36,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [37,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [38,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [39,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [40,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [41,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [42,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [43,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [44,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [45,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [46,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [47,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [48,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [49,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [50,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [51,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [52,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [53,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [54,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [55,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [56,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [57,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [58,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [59,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [60,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [61,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [62,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [63,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [64,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [65,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [66,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [67,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [68,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [69,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [70,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [71,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [72,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [73,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [74,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [75,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [76,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [77,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [78,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [79,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [80,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [81,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [82,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [83,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [84,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [85,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [86,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [87,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [88,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [89,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [90,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [91,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [92,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [93,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [94,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [95,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [32,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [33,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [34,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [35,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [36,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [37,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [38,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [39,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [40,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [41,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [42,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [43,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [44,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [45,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [46,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [47,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [48,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [49,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [50,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [51,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [52,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [53,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [54,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [55,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [56,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [57,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [58,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [59,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [60,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [61,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [62,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [274,0,0], thread: [63,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [64,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [65,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [66,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [67,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [68,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [69,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [70,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [71,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [72,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [73,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [74,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [75,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [76,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [77,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [78,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [79,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [80,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [81,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [82,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [83,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [84,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [85,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [86,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [87,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [88,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [89,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [90,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [91,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [92,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [93,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [94,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
/pytorch/aten/src/THC/THCTensorIndex.cu:272: indexSelectLargeIndex: block: [218,0,0], thread: [95,0,0] Assertion `srcIndex < srcSelectDimSize` failed.
Traceback (most recent call last):
  File "pretraining/openwebtext/pretrain_medium.py", line 321, in <module>
    main()
  File "pretraining/openwebtext/pretrain_medium.py", line 317, in main
    train(rank=args.gpu, args=args)
  File "pretraining/openwebtext/pretrain_medium.py", line 201, in train
    loss, loss_mlm, loss_disc, acc_gen, acc_disc, disc_labels, disc_pred = model(input_ids, attention_mask=input_mask, token_type_ids=segment_ids)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/project/6007309/lucidrains/electra-pytorch/electra_pytorch/electra_pytorch.py", line 184, in forward
    logits = self.generator(masked_input, **kwargs)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "pretraining/openwebtext/pretrain_medium.py", line 135, in forward
    return self.adaptee(*args, **kwargs)[0]
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/transformers/modeling_electra.py", line 621, in forward
    output_hidden_states,
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/transformers/modeling_electra.py", line 327, in forward
    hidden_states = self.embeddings_project(hidden_states)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/modules/linear.py", line 91, in forward
    return F.linear(input, self.weight, self.bias)
  File "/home/daabrams/tf2/lib/python3.7/site-packages/torch/nn/functional.py", line 1676, in linear
    output = input.matmul(weight.t())
RuntimeError: CUDA error: CUBLAS_STATUS_ALLOC_FAILED when calling `cublasCreate(handle)`

@DarrenAbramson I think I may have spotted the error. So the "max_position_embeddings": 512 needs to be increased to 768 as well, or you will hit an out of bounds when trying to get that positional encoding greater than the default (512)

Thanks, I should have seen that. Really appreciate the help.

No problem, I'll see if I can add a line of code to guard against that later tonight. Thanks for trying this out!

authors: DarrenAbramson lucidrains

repo: lucidrains/electra-pytorch


text:
Problem while trying to use more than 3 channels

I am trying an early fusion technique where i am having 6-7 channel input but the model T2TViT throws me the following error.
RuntimeError                              Traceback (most recent call last)
 in ()
2 img = torch.randn(1, 6, 448, 448)
3
----> 4 preds = v(img) # (1, 1000)
10 frames
/usr/local/lib/python3.7/dist-packages/torch/nn/functional.py in layer_norm(input, normalized_shape, weight, bias, eps)
2203             layer_norm, (input,), input, normalized_shape, weight=weight, bias=bias, eps=eps
2204         )
-> 2205     return torch.layer_norm(input, normalized_shape, weight, bias, eps, torch.backends.cudnn.enabled)
2206
2207
RuntimeError: Given normalized_shape=[147], expected input with shape [*, 147], but got input of size[1, 12544, 294]

Did you set the channels parameter? For me it works fine like this:
tnt = T2TViT(128, 100, 512, 4, 8, 2, channels=6)
print(tnt(torch.rand(1, 6, 128, 128)).shape)

torch.Size([1, 100])

it works but crashes with 10 channel image on colab pro.

Because the last channel of your data which is fed into LayerNorm is not matched with the parameters of nn.LayerNorm

how to slove？

repo: lucidrains/vit-pytorch


text:
🛑 Loxone is down

In ca82a94, Loxone (http://loxone.kerl.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Loxone is back up in e38982b.

repo: lucienkerl/status