[Issue]: ROCm 6.1.3 crashes on 7900XTX when generating images in Stable Diffusion

Problem Description
As requested in https://github.com/ROCm/ROCm/issues/3265 , I'm opening this separate issue since the recommendations listed there did not resolve the issue.
I am running this in an Ubuntu container, but the host and thus kernel is Gentoo.  Kernel is 6.9.9-gentoo-dist.
Attempting to generate images in Stable Diffusion crashes the card.  The graphical session is recoverable by remotely killing and restarting the X server.
Operating System
Ubuntu 22.04.4 LTS (Jammy Jellyfish)
CPU
AMD Ryzen 9 3950X 16-Core Processor
GPU
AMD Radeon RX 7900 XTX
ROCm Version
ROCm 6.1.0
ROCm Component
No response
Steps to Reproduce
Followed the exact steps as specified in https://github.com/ROCm/ROCm/issues/3265#issuecomment-2245358795
Installed ROCm 6.1.3:
$ cat /etc/apt/sources.list.d/rocm.list
deb [arch=amd64] https://repo.radeon.com/rocm/apt/6.1.3/ jammy main
$ dpkg-query --list '*rocm*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version                      Architecture Description
+++-======================-============================-============-===========================================================
ii  rocm                   <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) software stack meta package
ii  rocm-cmake             <IP_ADDRESS>103-122~22.04       amd64        rocm-cmake built using CMake
ii  rocm-core              <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-dbgapi            <IP_ADDRESS>103-122~22.04       amd64        Library to provide AMD GPU debugger API
ii  rocm-debug-agent       <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute Debug Agent (ROCdebug-agent)
ii  rocm-developer-tools   <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-device-libs       <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute - device libraries
ii  rocm-gdb               14.1.60103-122~22.04         amd64        ROCgdb
ii  rocm-hip-libraries     <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-hip-runtime       <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-hip-runtime-dev   <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-hip-sdk           <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-language-runtime  <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-llvm              <IP_ADDRESS>93.60103-122~22.04 amd64        ROCm core compiler
ii  rocm-ml-libraries      <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-ml-sdk            <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
un  rocm-ocl-icd           <none>                       <none>       (no description available)
ii  rocm-opencl            <IP_ADDRESS>103-122~22.04        amd64        clr built using CMake
ii  rocm-opencl-dev        <IP_ADDRESS>103-122~22.04        amd64        clr built using CMake
ii  rocm-opencl-icd-loader 1.2.60103-122~22.04          amd64        OpenCL-ICD-Loader built using CMake
ii  rocm-opencl-runtime    <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-opencl-sdk        <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocm-openmp-sdk        <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) OpenMP Software development Kit.
un  rocm-smi               <none>                       <none>       (no description available)
ii  rocm-smi-lib           <IP_ADDRESS>103-122~22.04        amd64        AMD System Management libraries
ii  rocm-utils             <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime software stack
ii  rocminfo               <IP_ADDRESS>103-122~22.04        amd64        Radeon Open Compute (ROCm) Runtime rocminfo tool

Clone stable diffusion repo.  Make changes as specified:
$ grep -E "^[^#]" webui-user.sh
export COMMANDLINE_ARGS="--no-half-vae --opt-sdp-attention"
export TORCH_COMMAND="pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torch-2.1.2%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torchvision-0.16.1%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/pytorch_triton_rocm-2.1.0%2Brocm<IP_ADDRESS>d510c3a44-cp310-cp310-linux_x86_64.whl"
export TORCH_BLAS_PREFER_HIPBLASLT=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_ROCM_ARCH=gfx1100
export HIP_VISIBLE_DEVICES=0
export PYTORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:512

Run and attempt to generate an image.
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
ROCk module is loaded
=====================
HSA System Attributes
=====================
Runtime Version:         1.13
Runtime Ext Version:     1.4
System Timestamp Freq.:  1000.000000MHz
Sig. Max Wait Duration:<PHONE_NUMBER>3709551615 (0xFFFFFFFFFFFFFFFF) (timestamp count)
Machine Model:           LARGE
System Endianness:       LITTLE
Mwaitx:                  DISABLED
DMAbuf Support:          YES

==========
HSA Agents
==========
*******
Agent 1
*******
  Name:                    AMD Ryzen 9 3950X 16-Core Processor
  Uuid:                    CPU-XX
  Marketing Name:          AMD Ryzen 9 3950X 16-Core Processor
  Vendor Name:             CPU
  Feature:                 None specified
  Profile:                 FULL_PROFILE
  Float Round Mode:        NEAR
  Max Queue Number:        0(0x0)
  Queue Min Size:          0(0x0)
  Queue Max Size:          0(0x0)
  Queue Type:              MULTI
  Node:                    0
  Device Type:             CPU
  Cache Info:
    L1:                      32768(0x8000) KB
  Chip ID:                 0(0x0)
  ASIC Revision:           0(0x0)
  Cacheline Size:          64(0x40)
  Max Clock Freq. (MHz):   3500
  BDFID:                   0
  Internal Node ID:        0
  Compute Unit:            32
  SIMDs per CU:            0
  Shader Engines:          0
  Shader Arrs. per Eng.:   0
  WatchPts on Addr. Ranges:1
  Features:                None
  Pool Info:
    Pool 1
      Segment:                 GLOBAL; FLAGS: FINE GRAINED
      Size:                    65750464(0x3eb45c0) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Recommended Granule:4KB
      Alloc Alignment:         4KB
      Accessible by all:       TRUE
    Pool 2
      Segment:                 GLOBAL; FLAGS: KERNARG, FINE GRAINED
      Size:                    65750464(0x3eb45c0) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Recommended Granule:4KB
      Alloc Alignment:         4KB
      Accessible by all:       TRUE
    Pool 3
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED
      Size:                    65750464(0x3eb45c0) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Recommended Granule:4KB
      Alloc Alignment:         4KB
      Accessible by all:       TRUE
  ISA Info:
*******
Agent 2
*******
  Name:                    gfx1100
  Uuid:                    GPU-5fc6ddc1dd71ff02
  Marketing Name:
  Vendor Name:             AMD
  Feature:                 KERNEL_DISPATCH
  Profile:                 BASE_PROFILE
  Float Round Mode:        NEAR
  Max Queue Number:        128(0x80)
  Queue Min Size:          64(0x40)
  Queue Max Size:          131072(0x20000)
  Queue Type:              MULTI
  Node:                    1
  Device Type:             GPU
  Cache Info:
    L1:                      32(0x20) KB
    L2:                      6144(0x1800) KB
    L3:                      98304(0x18000) KB
  Chip ID:                 29772(0x744c)
  ASIC Revision:           0(0x0)
  Cacheline Size:          64(0x40)
  Max Clock Freq. (MHz):   2304
  BDFID:                   3328
  Internal Node ID:        1
  Compute Unit:            96
  SIMDs per CU:            2
  Shader Engines:          6
  Shader Arrs. per Eng.:   2
  WatchPts on Addr. Ranges:4
  Coherent Host Access:    FALSE
  Features:                KERNEL_DISPATCH
  Fast F16 Operation:      TRUE
  Wavefront Size:          32(0x20)
  Workgroup Max Size:      1024(0x400)
  Workgroup Max Size per Dimension:
    x                        1024(0x400)
    y                        1024(0x400)
    z                        1024(0x400)
  Max Waves Per CU:        32(0x20)
  Max Work-item Per CU:    1024(0x400)
  Grid Max Size:<PHONE_NUMBER>(0xffffffff)
  Grid Max Size per Dimension:
    x<PHONE_NUMBER>(0xffffffff)
    y<PHONE_NUMBER>(0xffffffff)
    z<PHONE_NUMBER>(0xffffffff)
  Max fbarriers/Workgrp:   32
  Packet Processor uCode:: 202
  SDMA engine uCode::      21
  IOMMU Support::          None
  Pool Info:
    Pool 1
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED
      Size:                    25149440(0x17fc000) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Recommended Granule:2048KB
      Alloc Alignment:         4KB
      Accessible by all:       FALSE
    Pool 2
      Segment:                 GLOBAL; FLAGS: EXTENDED FINE GRAINED
      Size:                    25149440(0x17fc000) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Recommended Granule:2048KB
      Alloc Alignment:         4KB
      Accessible by all:       FALSE
    Pool 3
      Segment:                 GROUP
      Size:                    64(0x40) KB
      Allocatable:             FALSE
      Alloc Granule:           0KB
      Alloc Recommended Granule:0KB
      Alloc Alignment:         0KB
      Accessible by all:       FALSE
  ISA Info:
    ISA 1
      Name:                    amdgcn-amd-amdhsa--gfx1100
      Machine Models:          HSA_MACHINE_MODEL_LARGE
      Profiles:                HSA_PROFILE_BASE
      Default Rounding Mode:   NEAR
      Default Rounding Mode:   NEAR
      Fast f16:                TRUE
      Workgroup Max Size:      1024(0x400)
      Workgroup Max Size per Dimension:
        x                        1024(0x400)
        y                        1024(0x400)
        z                        1024(0x400)
      Grid Max Size:<PHONE_NUMBER>(0xffffffff)
      Grid Max Size per Dimension:
        x<PHONE_NUMBER>(0xffffffff)
        y<PHONE_NUMBER>(0xffffffff)
        z<PHONE_NUMBER>(0xffffffff)
      FBarrier Max Size:       32
*** Done ***

Additional Information
Stable Diffusion reports:
Model loaded in 2.7s (load weights from disk: 0.8s, create model: 0.3s, apply weights to model: 1.3s, calculate empty prompt: 0.2s).
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████| 20/20 [00:01<00:00, 17.95it/s]
Memory access fault by GPU node-1 (Agent handle: 0x55ac14d27600) on address 0x7f9587e00000. Reason: Page not present or supervisor privilege.s]
./webui.sh: line 304:  4388 Aborted                 "${python_cmd}" -u "${LAUNCH_SCRIPT}" "$@"

The following errors are emitted from the kernel:
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00801031
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: TCP (0x8)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x1
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: CB/DB (0x0)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: CB/DB (0x0)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: CB/DB (0x0)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: CB/DB (0x0)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:8 pasid:32783)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:  in process python pid 25698 thread python pid 25698)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x00007f9587e00000 from client 10
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          Faulty UTCL2 client ID: CB/DB (0x0)
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MORE_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          WALKER_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          PERMISSION_FAULTS: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          MAPPING_ERROR: 0x0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu:          RW: 0x0
[Tue Jul 23 13:49:25 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: failed to remove hardware queue from MES, doorbell=0x1002
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: MES might be in unrecoverable state, issue a GPU reset
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: Failed to evict queue 1
[Tue Jul 23 13:49:25 2024] print_sq_intr_info_error: 182 callbacks suppressed
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 1, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 1, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 1, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 1, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu: sq_intr: error, detail 0x00000000, type 2, sh 0, priv 1, wave_id 1, simd_id 0, wgp_id 0
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: GPU reset begin!
[Tue Jul 23 13:49:25 2024] amdgpu 0000:0d:00.0: amdgpu: Failed to remove queue 0
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=14
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_flush_shader_debugger [amdgpu]] *ERROR* failed to set_shader_debugger
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:26 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:27 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:27 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:27 2024] [drm:amdgpu_debugfs_mes_event_log_init [amdgpu]] *ERROR* MES failed to response msg=3
[Tue Jul 23 13:49:27 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[Tue Jul 23 13:49:27 2024] [drm:gfx_v9_4_2_set_power_brake_sequence [amdgpu]] *ERROR* failed to halt cp gfx
[Tue Jul 23 13:49:27 2024] amdgpu 0000:0d:00.0: amdgpu: MODE1 reset
[Tue Jul 23 13:49:27 2024] amdgpu 0000:0d:00.0: amdgpu: GPU mode1 reset
[Tue Jul 23 13:49:27 2024] amdgpu 0000:0d:00.0: amdgpu: GPU smu mode1 reset
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: GPU reset succeeded, trying to resume
[Tue Jul 23 13:49:28 2024] [drm] PCIE GART of 512M enabled (table at 0x0000008001300000).
[Tue Jul 23 13:49:28 2024] [drm] VRAM is lost due to GPU reset!
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: PSP is resuming...
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: reserve 0x1300000 from 0x85fc000000 for PSP TMR
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: RAP: optional rap ta ucode is not available
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: SMU is resuming...
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: smu driver if version = 0x0000003d, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x004e7e00 (78.126.0)
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: SMU driver if version not matched
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: SMU is resumed successfully!
[Tue Jul 23 13:49:28 2024] [drm] DMUB hardware initialized: version=0x07002A00
[Tue Jul 23 13:49:28 2024] [drm] kiq ring mec 3 pipe 1 q 0
[Tue Jul 23 13:49:28 2024] [drm] VCN decode and encode initialized successfully(under DPG Mode).
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: [drm:jpeg_v2_0_dec_ring_emit_ib [amdgpu]] JPEG decode initialized successfully.
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring vcn_unified_1 uses VM inv eng 1 on hub 8
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring jpeg_dec uses VM inv eng 4 on hub 8
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: recover vram bo from shadow start
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: recover vram bo from shadow done
[Tue Jul 23 13:49:28 2024] amdgpu 0000:0d:00.0: amdgpu: GPU reset(3) succeeded!

@matoro Internal ticket has been created to investigate this issue. Thanks!

Hi @matoro, thanks for the detailed issue report. I can confirm that I was able to reproduce your issue in some specific cases and am currently investigating. I'll detail my process so far.
Your output from dpkg-query --list '*rocm*' matches mine, so there does not appear to be an issue with ROCm component versions. In order to arrive at as similar a configuration as possible, I first uninstalled torch, torchvision, and triton to make sure I'm pulling the same versions as you, then applied your script
grep -E "^[^#]" webui-user.sh
export COMMANDLINE_ARGS="--no-half-vae --opt-sdp-attention"
export TORCH_COMMAND="pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torch-2.1.2%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torchvision-0.16.1%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/pytorch_triton_rocm-2.1.0%2Brocm<IP_ADDRESS>d510c3a44-cp310-cp310-linux_x86_64.whl"
export TORCH_BLAS_PREFER_HIPBLASLT=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_ROCM_ARCH=gfx1100
export HIP_VISIBLE_DEVICES=0
export PYTORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:512

to set the environment variables and ran webui.sh. I was able to generate a crash in this configuration.
There are two things I'd like to suggest for now. One is to try running Stable Diffusion with --listen, and accessing the webui from another machine on your network; when I did this I was able to repeatedly generate images without crashing. By default you can access the headless web UI through <the host machine's IP>:7860.
The other suggestion I have is to try setting up a venv before setting the environment variables and running Stable Diffusion as per https://are-we-gfx1100-yet.github.io/post/a1111-webui/; if you're already doing this and didn't specify or I missed it, I apologize. However, this was inconsistent for me when using a local web UI (i.e. not using the --listen flag); it worked fine multiple times, then I crashed with a local web UI outside of a venv, and following that crash when I went back into the venv to invoke the local web UI again I crashed. This might be due to some corruption that occurs following a crash, or it may just be inconsistent; I'll have to test it further.
Thanks again for your detailed report, there are several reports of Stable Diffusion crashes on the 7900XTX and other cards that we haven't been able to address and you've brought us one step closer to a solution. Let me know if either of my suggestions help you in the short term so we can narrow down the root cause. If neither of these help, I'll try to reproduce your Ubuntu-inside-Gentoo configuration.

Hi @matoro, thanks for the detailed issue report. I can confirm that I was able to reproduce your issue in some specific cases and am currently investigating. I'll detail my process so far.
Your output from dpkg-query --list '*rocm*' matches mine, so there does not appear to be an issue with ROCm component versions. In order to arrive at as similar a configuration as possible, I first uninstalled torch, torchvision, and triton to make sure I'm pulling the same versions as you, then applied your script
grep -E "^[^#]" webui-user.sh
export COMMANDLINE_ARGS="--no-half-vae --opt-sdp-attention"
export TORCH_COMMAND="pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torch-2.1.2%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torchvision-0.16.1%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/pytorch_triton_rocm-2.1.0%2Brocm<IP_ADDRESS>d510c3a44-cp310-cp310-linux_x86_64.whl"
export TORCH_BLAS_PREFER_HIPBLASLT=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_ROCM_ARCH=gfx1100
export HIP_VISIBLE_DEVICES=0
export PYTORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:512

to set the environment variables and ran webui.sh. I was able to generate a crash in this configuration.
There are two things I'd like to suggest for now. One is to try running Stable Diffusion with --listen, and accessing the webui from another machine on your network; when I did this I was able to repeatedly generate images without crashing. By default you can access the headless web UI through <the host machine's IP>:7860.
The other suggestion I have is to try setting up a venv before setting the environment variables and running Stable Diffusion as per https://are-we-gfx1100-yet.github.io/post/a1111-webui/; if you're already doing this and didn't specify or I missed it, I apologize. However, this was inconsistent for me when using a local web UI (i.e. not using the --listen flag); it worked fine multiple times, then I crashed with a local web UI outside of a venv, and following that crash when I went back into the venv to invoke the local web UI again I crashed. This might be due to some corruption that occurs following a crash, or it may just be inconsistent; I'll have to test it further.
Thanks again for your detailed report, there are several reports of Stable Diffusion crashes on the 7900XTX and other cards that we haven't been able to address and you've brought us one step closer to a solution. Let me know if either of my suggestions help you in the short term so we can narrow down the root cause. If neither of these help, I'll try to reproduce your Ubuntu-inside-Gentoo configuration.

Hey, thanks so much for looking at it.
First off, stable-diffusion already installs everything to a venv by default.  I don't install anything outside of a venv.
Secondly that snippet wasn't supposed to be a script for setting the environment variables, it was supposed to be demonstrating that I had them set in webui-user.sh, which webui.sh sources on startup.  That regex simply prints out all lines which are not commented out.  If you do the same thing, then grep -E "^[^#]" webui-user.sh should print the same list of exports.  That way, you won't have to set those variables every time you run, and you can tweak them before restarting stable-diffusion.

For posterity's sake, I just tried accessing the UI remotely using --listen, and it still crashed my card.  I can't imagine that has anything to do with it.
Besides - if stock stable-diffusion crashes at all, that is a problem.  If the output looks the same, both on the terminal and in dmesg, then it's probably the same issue.  Or are you saying that you observed crashes, but with different symptoms?

Hi, thanks for the quick response.
You're correct that Stable Diffusion installs and runs in a venv by default. The behaviour I experienced locally was that manually starting the venv before running fixed the crashes. However, frustratingly, so far today I am unable to reproduce any crashes with --no-half-vae enabled, regardless of manual venv or --listen flag. Running without --no-half-vae still crashes with the same dmesg output you're observing, but as you're crashing with this flag this doesn't seem to be causing your issue.
The next step on my end is to attempt reproduction inside a container in order to match your configuration better. This may be delayed a bit, but I'll update you when I have it set up. In the meantime, can you post the full output from running webui.sh? Also, I apologize if this seems redundant, but just to cover all the bases make sure the environment variables are actually being set and that the correct versions of torch, torchvision, and triton are installed.
I agree that stock Stable Diffusion crashing is an issue, the hope is that finding a consistent workaround will point toward the root cause.

Sure, here is the complete output when running and then attempting to generate an image.  I do not change any settings or put anything in the prompt.
$ ./webui.sh

################################################################
Install script for stable-diffusion + Web UI
Tested on Debian 11 (Bullseye), Fedora 34+ and openSUSE Leap 15.4 or newer.
################################################################

################################################################
Running on matoro user
################################################################

################################################################
Repo already cloned, using it as install directory
################################################################

################################################################
Create and activate python venv
################################################################

################################################################
Launching launch.py...
################################################################
glibc version is 2.35
Check TCMalloc: libtcmalloc_minimal.so.4
libtcmalloc_minimal.so.4 is linked with libc.so,execute LD_PRELOAD=/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4
Python 3.10.12 (main, Mar 22 2024, 16:50:05) [GCC 11.4.0]
Version: v1.9.4-295-g9f5a98d5
Commit hash: 9f5a98d5766b4ac233d916fe8b02ea16b8b2c259
Launching Web UI with arguments: --no-half-vae --opt-sdp-attention
no module 'xformers'. Processing without...
no module 'xformers'. Processing without...
No module 'xformers'. Proceeding without it.
Loading weights [6ce0161689] from /var/tmp/stable-diffusion-webui/models/Stable-diffusion/v1-5-pruned-emaonly.safetensors
Running on local URL:  http://<IP_ADDRESS>:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 6.3s (prepare environment: 1.5s, import torch: 1.7s, import gradio: 0.5s, setup paths: 1.5s, other imports: 0.3s, load scripts: 0.3s, create ui: 0.4s).
Creating model from config: /var/tmp/stable-diffusion-webui/configs/v1-inference.yaml
/var/tmp/stable-diffusion-webui/venv/lib/python3.10/site-packages/huggingface_hub/file_download.py:1150: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
Applying attention optimization: sdp... done.
Model loaded in 2.2s (load weights from disk: 0.5s, create model: 0.3s, apply weights to model: 1.1s, calculate empty prompt: 0.2s).
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████| 20/20 [00:01<00:00, 17.96it/s]
Memory access fault by GPU node-1 (Agent handle: 0x563187d2e580) on address 0x7fe6b8600000. Reason: Page not present or supervisor privilege.s]
./webui.sh: line 304:  1142 Aborted                 "${python_cmd}" -u "${LAUNCH_SCRIPT}" "$@"

Here are the complete contents of my webui-user.sh:
$ cat webui-user.sh
#!/bin/bash
#########################################################
# Uncomment and change the variables below to your need:#
#########################################################

# Install directory without trailing slash
#install_dir="/home/$(whoami)"

# Name of the subdirectory
#clone_dir="stable-diffusion-webui"

# Commandline arguments for webui.py, for example: export COMMANDLINE_ARGS="--medvram --opt-split-attention"
export COMMANDLINE_ARGS="--no-half-vae --opt-sdp-attention"

# python3 executable
#python_cmd="python3"

# git executable
#export GIT="git"

# python3 venv without trailing slash (defaults to ${install_dir}/${clone_dir}/venv)
#venv_dir="venv"

# script to launch to start the app
#export LAUNCH_SCRIPT="launch.py"

# install command for torch
#export TORCH_COMMAND="pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/rocm6.1"
export TORCH_COMMAND="pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torch-2.1.2%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/torchvision-0.16.1%2Brocm6.1.3-cp310-cp310-linux_x86_64.whl https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1.3/pytorch_triton_rocm-2.1.0%2Brocm<IP_ADDRESS>d510c3a44-cp310-cp310-linux_x86_64.whl"

# Requirements file to use for stable-diffusion-webui
#export REQS_FILE="requirements_versions.txt"

# Fixed git repos
#export K_DIFFUSION_PACKAGE=""
#export GFPGAN_PACKAGE=""

# Fixed git commits
#export STABLE_DIFFUSION_COMMIT_HASH=""
#export CODEFORMER_COMMIT_HASH=""
#export BLIP_COMMIT_HASH=""

# Uncomment to enable accelerated launch
#export ACCELERATE="True"

# Uncomment to disable TCMalloc
#export NO_TCMALLOC="True"

export TORCH_BLAS_PREFER_HIPBLASLT=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_ROCM_ARCH=gfx1100
export HIP_VISIBLE_DEVICES=0
export PYTORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:512

###########################################

i had similar crashes before, but on a different gfx version, when it reaches the final rendering before it renders the image the graphic card goes into limbo, the problem for my case was overheating, I tried adjust voltage/clocks in my case and the issue disappeared without changing any packages. But it could be a different scenario on your case, it would be helpful if you try to run again with a higher AMD_LOG_LEVEL=1 OR 2 to see whats going on.

i had similar crashes before, but on a different gfx version, when it reaches the final rendering before it renders the image the graphic card goes into limbo, the problem for my case was overheating, I tried adjust voltage/clocks in my case and the issue disappeared without changing any packages. But it could be a different scenario on your case, it would be helpful if you try to run again with a higher AMD_LOG_LEVEL=1 OR 2 to see whats going on.

Sure, here's a log of the issue with AMD_LOG_LEVEL=2 set:  out.log
I wouldn't expect it to be overheating-related, because I am using completely stock settings on my card with no overclocking, and further I am watching temps the entire time and never see it break 60C.  And I am not using anything intense, I am observing the crash while generating a single 512x512 image with stock settings on SD.  What settings did you change exactly?

I think you can also try level 3, that would output a lot more stuff, but its always interesting to see more traces, but I think these missing functions are not the real cause for you, but it may be good some good guy have a look into that  :)
What kernel version do you currently run? it may be related to the amdgpu kernel driver

I think you can also try level 3, that would output a lot more stuff, but its always interesting to see more traces, but I think these missing functions are not the real cause for you, but it may be good some good guy have a look into that :)

Sure, the log was too large to upload to github so here is a log capture taken with AMD_LOG_LEVEL=3.  I noticed also that this had some c++-mangled names in it, so I ran it through c++filt as well.

What kernel version do you currently run? it may be related to the amdgpu kernel driver

This most recent attempt is on kernel 6.10.2.  I have never been able to successfully generate an image or text on my card with any settings on any kernel.  Using it for compute in any capacity instantly causes this crash.

I wouldn't expect it to be overheating-related, because I am using completely stock settings on my card with no overclocking, and further I am watching temps the entire time and never see it break 60C. And I am not using anything intense, I am observing the crash while generating a single 512x512 image with stock settings on SD. What settings did you change exactly?

overheating can happen in a glimpse of a second and it may not be a real over heat but a hysteresis either hardware or software related (also monitor per second the status use rocm-smi ), for me down clocking the voltage and memory clock have helped maintain a consistent stable output.

Can you share exactly what settings you used?  I'm just tired of randomly flipping settings only to get the same results over and over.

i dont think that pruned model is more than 4 GB in size and that image generation should not take more than 2GB so in total you are using around 5-7GB so that out of memory is just a crashing procedure (maybe wrong address translation or any similar memory related issue) and not really an out of memory issue. but also driver related, rocm related, pytorch, etc all possibilities are open.

I am using the exact ROCm packages and pytorch packages that were specified by @schung-amd , an AMD employee, in https://github.com/ROCm/ROCm/issues/3265#issuecomment-2245358795 .  I can't imagine how this could be any closer to textbook at least from the userspace side.

Sure, the log was too large to upload to github so here is a log capture taken with AMD_LOG_LEVEL=3. I noticed also that this had some c++-mangled names in it, so I ran it through c++filt as well.

I think the card goes into limbo and its not any more an accessible resource at the point where it says out of memory or privileges. what does rocm-smi reports after its dead, does it actually have the card listed with all its correct parameters values, like temp, vram etc?
I saw that you wrote the card remains functional after the crash but is it really functional or its just have a framebuffer capability and not ROCm, or it can start the script without any problem and then crashes at 20/20?

This most recent attempt is on kernel 6.10.2. I have never been able to successfully generate an image or text on my card with any settings on any kernel. Using it for compute in any capacity instantly causes this crash.

So basically you tried earlier versions like 6.4?

Can you share exactly what settings you used? I'm just tired of randomly flipping settings only to get the same results over and over.

I actually did not understand which settings should I share :), the kernel parameters settings, or the DF parameters settings or which settings? also regarding kernel parameters are using any?

Sure, the log was too large to upload to github so here is a log capture taken with AMD_LOG_LEVEL=3. I noticed also that this had some c++-mangled names in it, so I ran it through c++filt as well.

I think the card goes into limbo and its not any more an accessible resource at the point where it says out of memory or privileges. what does rocm-smi reports after its dead, does it actually have the card listed with all its correct parameters values, like temp, vram etc?
I saw that you wrote the card remains functional after the crash but is it really functional or its just have a framebuffer capability and not ROCm, or it can start the script without any problem and then crashes at 20/20?

Yes, as soon as the driver resets the card (after the line that says amdgpu: GPU reset(3) succeeded!) then it resumes being fully functional, except that the Xorg session freezes.  It continues displaying a frozen image of whatever was on screen at the time of the crash.  If I ssh in and kill the Xorg session and start a new one, the new session is fully functional.

This most recent attempt is on kernel 6.10.2. I have never been able to successfully generate an image or text on my card with any settings on any kernel. Using it for compute in any capacity instantly causes this crash.

So basically you tried earlier versions like 6.4?

I've periodically tried this at least once on all major kernel releases since support was added, which is a pretty recent version.  I don't think 7900XTX was supported as far back as kernel 6.4.  Regardless, I've tried on 6.9 and 6.10 at least in this thread.

Can you share exactly what settings you used? I'm just tired of randomly flipping settings only to get the same results over and over.

I actually did not understand which settings should I share :), the kernel parameters settings, or the DF parameters settings or which settings? also regarding kernel parameters are using any?

My full kernel command line is:
ro debug amd_iommu=pt pcie_acs_override=downstream rd.driver.pre=vfio-pci mitigations=off transparent_hugepage=never rcu_nocbs=8-15,24-31 nohz_full=8-15,24-31 clocksource=tsc acpi_enforce_resources=lax amdgpu.ppfeaturemask=0xffffffff amdgpu.mcbp=0

Some of those are related to running virtual machines - since my 7900XTX does not work for compute, I pass through an NVIDIA card to a virtual machine.  The last two items especially (amdgpu.ppfeaturemask=0xffffffff amdgpu.mcbp=0) were recommended by other users who reported that it solved their problems, but neither of them has worked for me.
You said earlier:

for me down clocking the voltage and memory clock have helped maintain a consistent stable output.
That is what I am looking for.  Can you please specify what voltage and memory clock you set?

sure, the voltages and clocks can be adjusted using normal cat and echo command lines on the sys/fs files, here is a repo that does that in a nice script, thanks to this guy:) https://github.com/sibradzic/amdgpu-clocks if you need the actual values for the clock and voltages then my numbers are not going to help you because they are not for RX7900X but what you can do, is look into the current table and try to down it by a factor of 10%
The boot params looks good, and I think just for a temporary test, which is not really good (because it disables the dynamic power management of the card) but try it to see if that also crashes amdgpu.dpm=0
I recommend removing the rest of the params except the ppfeaturemask and amd_iommu to make sure nothing is causing out of control behavior which is mostly not the case.

Thank you for this, the above was enough to finally get a session where I was able to generate images.
After I confirmed that it was successfully stable, I tried to reduce the options one-by-one to come up with a set of options which would reliably reproduce the problem.  However, what I found out instead is that the issue is not reproducible on-demand.  Some option sets would crash, so I would remove an option and try again, get no crash, then go back to the one that originally showed it and get no crash.  At least I did observe that if it crashed, it would do so on the first image generation.  If it generated a single image and didn't crash, then generating further images regardless of model would also not crash.
I was able to at one point completely empty my COMMANDLINE_ARGS variable and not get a crash.  The best option seems to be as above:
export COMMANDLINE_ARGS="--opt-split-attention --no-half-vae --precision full --no-half"

as I never got a crash on this configuration.  Unfortunately, seems that since the problem is intermittent when changing options, and the same sets of options do not always trigger it, it might be hard to track down.
Additionally there's no guarantee that it's not a stateful issue, where switching the options itself is what triggers the problem.

Thanks for following up on this, I'm glad you were able to get things working. @smirgol I noticed you're on ROCm 6.2 now; out of curiosity, do you crash without --no-half on ROCm 6.1.x, or is this behavior new to ROCm 6.2? Our internal reproduction of the crash on ROCm 6.1.3 was fixed with --no-half-vae alone, but I wonder if we were just "fortunate" in not requiring --no-half for some reason, and in retrospect requiring both makes sense as both are related to FP16 support. Stable Diffusion crashes on the 7900XTX have been reported from time to time and we've had a hard time reproducing the crashes internally, so this is a good data point.
Looking at the A1111 repo, it seems like both --no-half and --no-half-vae are known to be necessary on some AMD cards (e.g. https://github.com/vladmandic/automatic/discussions/1041, also see --no-half requirement stated for some AMD cards in https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Install-and-Run-on-AMD-GPUs), but it appears these flags were automatically set at some point and are no longer, so some of the intermittent nature of this issue might be due to A1111 version differences.
@matoro If the issue appears to be solved on your end after a while, please close this issue, or I'll close this if I don't hear any further issues by the end of the week; but feel free to reopen or make a new issue if you start experiencing these crashes again. It seems like half precision is a common pain point for Stable Diffusion configurations in general, and I don't know if an internal solution is possible.


How to integrate with some third party player

Our company using a DRM player from https://castlabs.com/
They using videojs and shaka player for web version
And using an SDK for Android and iOS.
How to integrate p2p-media-loader with their player?

We integrate with video.js using one of hls.js plugins:

example with videojs-hlsjs-plugin: https://cdn.streamroot.io/videojs-hlsjs-plugin/1/stable/videojs-hlsjs-plugin.js

example with videojs-contrib-hls.js plugin: https://github.com/Novage/p2p-media-loader/blob/master/p2p-media-loader-hlsjs/demo/videojs-contrib-hlsjs.html

Here you can find implementations of functions for both plugins (
initVideoJsContribHlsJsPlayer and initVideoJsHlsJsPlugin) that do the integration: https://github.com/Novage/p2p-media-loader/blob/b33a214df3b5ed54b49d81e4513bd62e3c42c298/p2p-media-loader-hlsjs/lib/index.ts#L46

How can i use p2p-media-loader on some platform like: Android, Webos LG smartTV, Samsung Tizen smartTV?

@quanghuy1288, currently only in a WebView component or some framework based on WebView like React Native - running HTML5 player with P2P script there.
Currently no native implementation for Android and iOS that require using native WebRTC implementation without JavaScript at all like:

https://webrtc.org/native-code/android/
https://webrtc.org/native-code/ios/


NP-687: Add networking to Infrastructure CRD

This allows users to specify the IP address pools for nodes.

/hold
Wait until https://github.com/openshift/enhancements/pull/1340 is accepted.


Building and running in Xcode 11 not placing the congratulatory call.

Description
Building and running in Xcode 11 not placing the congratulatory call.
Steps to Reproduce

Build and run the app as described in the Readme.
Once app running in Simulator, click Call.
NSLog output:

2019-06-27 23:54:39.696363 SwiftVoiceCallKitQuickstart[68059:6179509] StartCallAction transaction request successful
2019-06-27 23:54:39.704199 SwiftVoiceCallKitQuickstart[68059:6177834] provider:performStartCallAction:
2019-06-27 23:54:40.099340 SwiftVoiceCallKitQuickstart[68059:6177834] provider:performEndCallAction:
2019-06-27 23:54:40.271448 SwiftVoiceCallKitQuickstart[68059:6177834] provider:didActivateAudioSession:
2019-06-27 23:54:40.312686 SwiftVoiceCallKitQuickstart[68059:6177834] provider:didDeactivateAudioSession:
2019-06-27 23:54:41.524318 SwiftVoiceCallKitQuickstart[68059:6177834] Call disconnected

Expected Behavior
Hear the default congratulatory message.
Actual Behavior
Call button goes gray for a few seconds, then goes back to red.
Reproduces How Often
All the time.
Versions
Pulled latest of everything just now.

Hi @nabeards
Did you receive the callDidConnect: callback? Could you provide a Call SID when the issue you described happened?
Thanks
-bobie

Hi @bchen-twilio,
Thanks for the reply! I included the NSLog entries to show what was firing; unfortunately, it doesn't appear that callDidConnect: ever fires. How would I see the Call SID so I can report it to you?

Hi @nabeards
Could you check if your TwiML endpoint is returning correct TwiML response? You can also check out the Voice Dashboard and see if there is any errors logged related to the call you are making.
-bobie

Thanks again. There are no calls displayed when I go to Call Logs in the dashboard.
I am using the Node.js Quickstart server, can see the Token being generated and sent, and accessing https://{url}/makeCall via cURL gives the following response:
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 127
ETag: W/"7f-30HwhFfDAd5xhbi2/j+PU3tAHdY"
Date: Mon, 01 Jul 2019 18:14:18 GMT

<?xml version="1.0" encoding="UTF-8"?><Response><Say>Congratulations! You have made your first call! Good bye.</Say></Response>

Of note: Downloading the latest version of master appears to have broken Carthage building, adding to more frustration with trying to get this to work. Running carthage update or carthage bootstrap results in no build placed in Carthage/Build, so I can no longer just re-download and build.

Here's what I'm doing now:

Download Zip of master
Modify Cartfile with: github "twilio/twilio-voice-ios" == 3.1.1
Run carthage bootstrap
I get a built framework now, drag and drop that to my Xcode project and follow all the other directions for the build

I can build and run the app, but before it loads I just get a SIGABRT on line 50 of ViewController.swift.

Thanks for the update @nabeards. Is there any error or warning logged in the Errors & Warnings section at the top-right side of the dashboard?
We are aware of the Carthage issue of the 4.0 SDK and are working on it.
Can you provide more details such as the stack of the SIGABRT crash?
-bobie

I assume you mean under the Debugger? Here is all that I see:

Here's the full stack trace:
2019-07-01 15:28:52.400344-0400 SwiftVoiceQuickstart[91256:8695767] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'PushKit apps that use VoIP push must link either CallKit or IncomingCallNotifications frameworks.'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000010cd88b6e __exceptionPreprocess + 350
	1   libobjc.A.dylib                     0x000000010c723f57 objc_exception_throw + 48
	2   CoreFoundation                      0x000000010cd888e8 +[NSException raise:format:arguments:] + 88
	3   Foundation                          0x000000010c155c29 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
	4   PushKit                             0x000000010d940b12 +[PKPushRegistry _checkIfNecessaryVoIPFrameworksAreLinked] + 251
	5   PushKit                             0x000000010d940dc0 -[PKPushRegistry _registerForPushType:] + 287
	6   PushKit                             0x000000010d941843 __38-[PKPushRegistry setDesiredPushTypes:]_block_invoke + 240
	7   libdispatch.dylib                   0x000000010fd59ed0 _dispatch_client_callout + 8
	8   libdispatch.dylib                   0x000000010fd68a88 _dispatch_lane_barrier_sync_invoke_and_complete + 132
	9   PushKit                             0x000000010d941732 -[PKPushRegistry setDesiredPushTypes:] + 108
	10  SwiftVoiceQuickstart                0x000000010b41c45a $s20SwiftVoiceQuickstart14ViewControllerC5coderACSgSo7NSCoderC_tcfc + 2346
	11  SwiftVoiceQuickstart                0x000000010b41c803 $s20SwiftVoiceQuickstart14ViewControllerC5coderACSgSo7NSCoderC_tcfcTo + 51
	12  UIKitCore                           0x000000011b3c1d68 -[UIClassSwapper initWithCoder:] + 2427
	13  UIFoundation                        0x000000011e9cb4d6 UINibDecoderDecodeObjectForValue + 744
	14  UIFoundation                        0x000000011e9cb1e1 -[UINibDecoder decodeObjectForKey:] + 251
	15  UIKitCore                           0x000000011b3c6092 -[UIRuntimeConnection initWithCoder:] + 160
	16  UIFoundation                        0x000000011e9cb4d6 UINibDecoderDecodeObjectForValue + 744
	17  UIFoundation                        0x000000011e9cb77d UINibDecoderDecodeObjectForValue + 1423
	18  UIFoundation                        0x000000011e9cb1e1 -[UINibDecoder decodeObjectForKey:] + 251
	19  UIKitCore                           0x000000011b3c0e36 -[NSCoder(UIIBDependencyInjectionInternal) _decodeObjectsWithSourceSegueTemplate:creator:sender:forKey:] + 450
	20  UIKitCore                           0x000000011b3c3ba5 -[UINib instantiateWithOwner:options:] + 1145
	21  UIKitCore                           0x000000011b8a6854 -[UIStoryboard __reallyInstantiateViewControllerWithIdentifier:creator:storyboardSegueTemplate:sender:] + 279
	22  UIKitCore                           0x000000011b8a66ff -[UIStoryboard _instantiateViewControllerWithIdentifier:creator:storyboardSegueTemplate:sender:] + 97
	23  UIKitCore                           0x000000011b74a894 -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 167
	24  UIKitCore                           0x000000011b74ae48 -[UIApplication _loadMainInterfaceFile] + 274
	25  UIKitCore                           0x000000011b7497a9 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1025
	26  UIKitCore                           0x000000011aeb6e8c -[_UISceneLifecycleMultiplexer completeApplicationLaunchWithFBSScene:transitionContext:] + 122
	27  UIKitCore                           0x000000011b3838a0 _UIScenePerformActionsWithLifecycleActionMask + 78
	28  UIKitCore                           0x000000011aeb7993 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 198
	29  UIKitCore                           0x000000011aeb745f -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 474
	30  UIKitCore                           0x000000011aeb77c3 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 810
	31  UIKitCore                           0x000000011aeb7060 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 345
	32  UIKitCore                           0x000000011aebb3ca __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke_2 + 159
	33  UIKitCore                           0x000000011b2ae08e +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:actions:completion:] + 845
	34  UIKitCore                           0x000000011b3a165c _UISceneSettingsDiffActionPerformChangesWithTransitionContext + 240
	35  UIKitCore                           0x000000011aebb009 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 171
	36  UIKitCore                           0x000000011b3a155f _UISceneSettingsDiffActionPerformActionsWithDelayForTransitionContext + 84
	37  UIKitCore                           0x000000011aebae68 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 359
	38  UIKitCore                           0x000000011ad299b7 __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke + 657
	39  UIKitCore                           0x000000011ad28930 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 374
	40  UIKitCore                           0x000000011ad296e1 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 210
	41  UIKitCore                           0x000000011b748126 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 535
	42  UIKitCore                           0x000000011b2ce77d -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 361
	43  FrontBoardServices                  0x0000000116e85b69 -[FBSSceneImpl _callOutQueue_agent_didCreateWithTransitionContext:completion:] + 442
	44  FrontBoardServices                  0x0000000116eae168 __86-[FBSWorkspaceScenesClient sceneID:createWithParameters:transitionContext:completion:]_block_invoke.160 + 102
	45  FrontBoardServices                  0x0000000116e90a99 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 220
	46  FrontBoardServices                  0x0000000116eaddf9 __86-[FBSWorkspaceScenesClient sceneID:createWithParameters:transitionContext:completion:]_block_invoke + 355
	47  libdispatch.dylib                   0x000000010fd59ed0 _dispatch_client_callout + 8
	48  libdispatch.dylib                   0x000000010fd5ce41 _dispatch_block_invoke_direct + 300
	49  FrontBoardServices                  0x0000000116ed522b __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 30
	50  FrontBoardServices                  0x0000000116ed4f12 -[FBSSerialQueue _performNext] + 436
	51  FrontBoardServices                  0x0000000116ed5433 -[FBSSerialQueue _performNextFromRunLoopSource] + 33
	52  CoreFoundation                      0x000000010ccec371 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	53  CoreFoundation                      0x000000010ccec301 __CFRunLoopDoSource0 + 81
	54  CoreFoundation                      0x000000010ccebad4 __CFRunLoopDoSources0 + 180
	55  CoreFoundation                      0x000000010cce67ef __CFRunLoopRun + 1263
	56  CoreFoundation                      0x000000010cce5fd6 CFRunLoopRunSpecific + 438
	57  GraphicsServices                    0x000000011675a9f8 GSEventRunModal + 65
	58  UIKitCore                           0x000000011b74b722 UIApplicationMain + 1621
	59  SwiftVoiceQuickstart                0x000000010b42e908 main + 72
	60  libdyld.dylib                       0x000000010fde26ad start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Hi @nabeards
Could you please help us check if the Application SID in the access token is pointing to your latest TwiML endpoint's URL? A .trace level SDK log would also be useful for us to debug the issue.
The crash stack does not seem to be anything to do with the SDK itself. Could you check the Swift compiler version in your Xcode project settings and make sure PushKit is properly integrated, while I am trying the same thing on Xcode 11 beta.
Thanks,
-bobie

Within TwiML, I can place a test call using the Call button to the right of my request URL, and that goes through OK. I am currently downloading Xcode 11 beta 2 to see if that makes any difference, and will verify your other settings and run a full trace level if not.

With Xcode 11 beta 2, I was able to make the call just fine from the Simulator! Not sure what the different between the two versions could be, but apparently some difference there. Should I test with the 4.0.0 version of the SDK just to wrap everything up?

Hi @nabeards
Thanks for the updates. We can use the SDK logs of the call to investigate the root cause why you are not hearing the congratulatory message on the device.
We've updated the 4.0.0 release artifacts so you should be able to integrate the framework via the Carthage library now.
Thanks,
-bobie

Thanks @bchen-twilio
I went ahead and updated to the 4.0.0 release, and all is still working well for me in the simulator. I don't currently have testing setup to a device, so I don't know that it's working there, but I'm good with having it in the simulator so I can continue development.
Thanks for all of your help.
nabeards


refactor: Client Classes & Azure OpenAI as a separate Endpoint

In progress, refactoring to decouple node-chatgpt-api dependency.
This over #527 since I'm taking the time to make a bigger refactor for easier additions/scalability of AI clients.
I will leave the client-refactor branch up for those that want to test localAi support, since it's not fully supported with this refactor yet.

oh one more thing, if you get a chance while you're in here. It'd be cool to be able to have the frame work for defining your own STOP, I often want to use END_CODE for a stop point for example

The small issues I previously had are now fixed 👍

oh one more thing, if you get a chance while you're in here. It'd be cool to be able to have the framework for defining your own STOP, I often want to use END_CODE for a stop point for example

On this, I will do this in a separate PR right after this one. I want to get this functionality in first

closes #548


Count number of relations in relna/LocText corpus for SS and DS modals (D0, D1, D2, D3 and D4+)

The function which performs the count is as follows:
count_true_relations_in_same_and_diff_sentences(dataset, rel_type)

dataset : normal dataset
rel_type: 'r_4' for relna and 'r_5' for LocText

The file path: nalaf/structures/count_of_relations_in_ss_and_ds.py
Import statement: from nalaf.structures.count_of_relations_in_ss_and_ds import count_true_relations_in_same_and_diff_sentences
data.py file has been modified: 1342 line has been commented to avoid assertion error, that occurs when there is an entity of type 'None'.
Branch in nalaf: feature/CountRelations
Current findings in relna:
********************* True relation count is as follows **********************
D0 - relations in Same sentences ----------------------------------------->  304
D1 - relations in sentences which are 1 sentence apart. ------------------>  8
D2 - relations in sentences which are 2 sentence apart. ------------------>  1
D3 - relations in sentences which are 3 sentence apart. ------------------>  0
D4+ - relations in sentences which are 4 or more than 4 sentence apart --->  1
************************* END *************************

👍


Add support for Vivaldi browser

Extension
https://www.raycast.com/dru89/obsidian-bookmarks
Description
Please add support for Vivaldi browser.
Who will benefit from this feature?
Obsidian, Vivaldi, Raycast users.
Anything else?
No response

@raycastbot close this issue


[Suggestion] Update the logic of preprocessing for efficiency

Suggest to update the logic of preprocessing for efficiency.
In many cases, a user's behavior sequence is the same for all training samples. In addition, the features of a user or an item are often the same for all training samples.
However, the current version of FuxiCTR receives the training dataset as a single DataFrame, so these features (e.g., a user's behavior sequence, the features of a user or an item) should be stored redundantly in that DataFrame, which consumes too much memory (especially, in large-scale dataset). Also, fit/transform of feature_preprocessor should be performed on redundant behavior sequences and features, which takes too long (especially, in large-scale dataset).
So, to operate more efficiently, I hope these redundancies are removed. To this end, I suggest to change the logic of preprocessing to receive user_df and item_df for each dataset together and fit/transform unique features (i.e., user_df and item_df).

Thanks for the suggestion. If decoupling the dataset to user_df and item_df, the dataset cannot handle some cross features and real-time sequences. In some datasets we have tested, a user has different sequences which are computed according to the timestamp. It follows the common practice in industry. But the preprocessing should be accelerated if we partition the dataset into chunks and remove some redundancy.


Client SDK using NVP devops

To start the client SDK, we can use the devops module from NVP and refit the Javascript code to use gRPC instead of REST.

We close this issue and open up others as we discovered more work to be done in this area


Cannot open notification if it was a new commit to PR.

If there was a comment on a PR or issue, it works fine.
If the notification is generated by a new commit in a pull request, you get same error as #87.

Sry, I was not able to release patch for #87 yet, itis probably same problem. Will try to release it ASAP.

After some investigation I found other problem. Github REST API sometimes returns 'null' String instead of null value, so I improved response parsing a bit to workaround this ;-)

tyvm


Added missing changelog entry for zhmcclient 1.16.1

No review needed.

coverage: 25.088%. remained the same
when pulling 2162deeec326374d099f0e7f5fcb14c7708e2b5a on andy/zhmcclient-changelog
into ddbb2ee2dd22410c3fb9b19b0d9b535045c24933 on master.


[WIP] Dropdown component for design panel

Part of Issue #255
Summary
Create dropdown component that will be used in design panel.
Todo:

[X] : Create dropdown component based on figma design
[ ] : Keyboard accessible
[ ] : Multiple select
[ ] : Search feature need to be integrated

Question:
For @swissspidy @barklund
I think font picker is kind of dropdown. Do we need to build that kind of universal feature dropdown or just need normal dropdown with single select?

This PR is to create a dropdown for design panel that addresses issue #255
Basically I think there could be two types of dropdown. One if font picker dropdown that has search. I want to confirm if it is the correct direction to develop multiple select, searchable dropdown for this one or do we have separate issue for font picker dropdown?
@swissspidy @barklund @wassgha @jauyong

Yes, we have #309 specifically for the font picker. We can handle that more complex dropdown functionality there.

Can this shame dropdown be reused for the media library?

I wanted to test this, but storybook didn't work and this dropdown is not implementing anywhere.

@spacedmonkey Storybook is not working in what sense? npm run storybook is broken, or the story in this particular PR?

@swissspidy Storybook worked but when I clicked on the nothing appears.

Can this shame dropdown be reused for the media library?

@spacedmonkey  Yes, it should. But some minor update required for the main select styling. Currently it's focusing on design panel dropdown so the background layout and the icon should be updated for media panel dropdown.

Should we remove / replace select.js?

@barklund @spacedmonkey Currently it can't get escape keydown event. Any ideas how to handle escape event from element? Thank you

Did you try useKeyDownEffect hook https://github.com/google/web-stories-wp/blob/master/assets/src/edit-story/components/keyboard/index.js @ndev1991 ?

Did you try useKeyDownEffect hook https://github.com/google/web-stories-wp/blob/master/assets/src/edit-story/components/keyboard/index.js#L96 @ndev1991 ?

@obetomuniz It works! Thanks

In a next step it would be great to actually use this new component in the editor where appropriate.

In a next step it would be great to actually use this new component in the editor where appropriate.

@swissspidy Can we do it in separate PR? Or just in this PR?

Separate PR is fine; you could even start with one already that is just based off this branch. This way we can more easily spot issues with the component that need to be addressed in this PR.

Reach by the way has a really nicely done and perfectly accessible React listbox component (not a dropdown though, just an open list) - good for inspiration.

Reach by the way has a really nicely done and perfectly accessible React listbox component (not a dropdown though, just an open list) - good for inspiration.

Thank you @barklund

@swissspidy @dvoytenko @miina do you have some times to review this PR so we can merge it? Thank you

@ndev1991 Please merge master -- note that textStyle.js is not one file anymore but there is textStyle folder now including different parts of the text panel.

@ndev1991 Please merge master -- note that textStyle.js is not one file anymore but there is textStyle folder now including different parts of the text panel.

@miina latest master branch merged and lint issue fixed. Ready now! 🐰

@ndev1991 Editor is crashing when testing with font select for Text element. Working OK for you?

@ndev1991 Editor is crashing when testing with font weight select for Text element. Working OK for you?

@miina It's crashing for me also. The issue was the difference between number and string. The font weights options has string value like "400" and the actual value coming to 400 as number.
Now fixed it by converting all to toString()!

LGTM, we can follow up in other PR-s if something comes up.

Sounds good. It's ready to merge now!


chore: cleanup pkg/config globals

Cleanup the global variables in pkg/config

Double check if we need to introduce locking

Double check if we need to introduce locking

It looks like the set functions are only called in one place. all the rest are gets - so this should be fine without locking.

@sthaha @sunya-ch can you take a look too? thanks

Hi @sthaha
I incorporated the suggested changes. Please let me know if there's anything else.
Thanks
Maryam


[1.18, Bug] Offset and normal sized Firework Explosions

did not get this
however, for some reason, a firework spawned with like -1.4k x velocity and froze the client instantly


Should add overloaded multiPart method that accepts InputStream or byte[] instead of File or String

From<EMAIL_ADDRESS>on August 22, 2012 21:08:27
There should be a variant of the multiPart method that allows to specify the data as byte[] or as InputStream. One usecase if is the binary file to be uploaded is present in the resource fork.
Original issue: http://code.google.com/p/rest-assured/issues/detail?id=191

From<EMAIL_ADDRESS>on August 22, 2012 22:39:42
There already is support for byte[] and inputstreams as overloaded methods. See https://github.com/jayway/rest-assured/blob/master/examples/rest-assured-itest-java/src/test/java/com/jayway/restassured/itest/java/MultiPartUploadITest.java .
Status: Invalid

From<EMAIL_ADDRESS>on August 23, 2012 11:44:43
Ok, thanks. Now found the javadoc ( http://rest-assured.googlecode.com/svn/tags/1.6.2/apidocs/com/jayway/restassured/specification/RequestSpecification.html ). Found no way to get rid of the fileName attribute but this is a minor thing. Now I'm looking for a way to add a content-Language header to the section.

From<EMAIL_ADDRESS>on August 23, 2012 12:06:52
Please use the mailing-list for asking questions.


Configure Amazon SES email support in staging env

Overview
Adds Terraform resources and configures Django appropriately via django-amazon-ses to send emails from staging env through Amazon SES. Updates the Django DEFAULT_FROM_EMAIL to include a default if an environment variable doesn't exist.

[x] Submit support request to move out of the SES sandbox for staging (confirming language on slack before submitting)

Closes #95 #80
Demo

Notes

While I set a default from email in Django SETTINGS, Terraform still expected a default_from_email variable within the terraform/terrafrom.tfvars file on S3. While not documented in the git history of this branch, this PR also includes adding the below line to that S3 file for terraform to build:
default_from_email =<EMAIL_ADDRESS>
Testing Instructions

scripts/server
Navigate to /login and select 'Forgot password'
Confirm email logs to console in development environment
While in the SES Sandbox we'll need to either create a verified email identity to test sending emails or confirm email sent through the SES dashboard. I created a verified email identity to test and followed these instructions
Create a User in the admin that corresponds to a verified email identity
Navigate to https://staging.iow.azavea.com/forgot
Add email to form and click "continue"
Confirm email sent to inbox of verified email identity or view updated graph in SES dashboard

Checklist

[x] fixup! commits have been squashed
[x] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[x] README.md updated if necessary to reflect the changes
[ ] CI passes after rebase

Taking a quick look


[Wave 6: Workspace Chats] Unread marker missing for payer after money request in DM

Reproduction steps

On NewDot, log in to accounts for user A and user B (in separate browsers or incognito)
Request money as user A from user B

Expected result
User B (the payer) sees the DM bolded in the LHN to indicate unread, and upon clicking the chat, sees a green line above the unread message
Actual result
User B (the payer) sees the DM bolded in the LHN to indicate unread, and upon clicking the chat, does not see a green line above the unread message
Video
https://github.com/Expensify/App/assets/7277067/17732b67-af3a-4828-afd7-e2bd6611bad7

@waterim as a first step can you try just reproducing? The video in the OP is a few days old, and I'm trying to repro again now and am having difficulty doing so. I'm updating all my repos to the latest main though and will try again.

Test on latest main everywhere, not reproducible:
https://github.com/Expensify/App/assets/7277067/ca7fe86b-2402-458f-9816-f6516dc9893d

@amyevans
I was able to reproduce, but it seems to work randomly sometimes

Were the repro steps the same as what's currently written?

@amyevans Yes, it looks like I can reproduce it 70/30, 70% reproducible, 30% not

Any patterns noticed or leads here?

@amyevans No, but looking more precisely now, will try to fix today

After pulling main again, cant reproduce anymore :D

Okay thanks, I tested again and am always seeing the green line, so let's close this out

Thanks y'all!


Package request: Rill

Project description
Dashboards that move as fast as your business. Unlike most BI tools, Rill comes with its own embedded in-memory database. Data and compute are co-located, and queries return in milliseconds. So you can pivot, slice, and drill-down into your data instantly.
Metadata

homepage URL: https://www.rilldata.com/
source URL: https://github.com/rilldata/rill
license:  Apache-2.0 license
platforms: linux

@KCynk I created a pull request https://github.com/NixOS/nixpkgs/pull/323429 based on this package request. Merging it will close this issue.

Would love to get this merged! Big fan of Rill


Respect SSL_OP_NO_TICKET

Implement support for stateful TLSv1.3 tickets, and use them if SSL_OP_NO_TICKET is set.
Additionally during anti-replay we cache the ticket anyway, so there is no point in using a full stateless ticket so we act as if SSL_OP_NO_TICKET were set in that case.
Fixes #6391.
Note: This touches some of the same code as #6469, so if that one lands first this one may need some small tweaks.

Checklist

[x] documentation is added or updated
[x] tests are added or updated

This is marked as WIP because it includes the commit from #6561. Once that one is approved I can rebased this and take it out of WIP.

This seems somewhere between a bug fix and a feature to me. Probably, to be on the safe side, we should get 2 OMC approvals.

I rebased this to pick up the fix from #6561. I also addressed the comment from @vdukhovni.
This is now out of WIP.

Fixup commits pushed addressing comments so far.

Thanks. I think this one will need 2 OMC approvals - so I now need a second one!

Pushed. Thanks.

@mattcaswell it seems like the use of stateful tickets for TLS 1.3 as implemented here violates some design assumptions that had previously been in place for our TLS 1.3 implementation.  Specifically, we assume that every TLS 1.3 connection gets a new SSL_SESSION, and thus that it is safe (in a thread-safety sense) to write to it during the handshake.  For example, see final_server_name() where we write to s->session->ext.hostname on the server for new handshakes and TLS 1.3 handshakes.
I am not confident that we would succeed in enumerating all places where this assumption was made, so my preference would be to add another argument to lookup_sess_in_cache() to differentiate the TLS-1.3 from legacy cases: the TLS 1.3 case would do SSL_SESSION_dup(), and atomically remove the old session from the cache if we are allowing 0-RTT data.


fix: path not found on windows

Fixes https://github.com/tauri-apps/tauricon/issues/23

Thanks for the contribution, but please give some details (tracking issue, for example) and explain how you have tested this. Also, you should note the addition you made to ignore certain directories.
Sidenote: we need to add a template for PRs / Issues.

Can you provide more info about the error? Nobody reported it so far and i did 95% of my testing on windows too and never encountered it.

updated with issues


vimc-5265 create YT tickets on report run failure

If a diagnostic report fails to run for any reason, create a YT ticket with the summary "Run, check & share diagnostic report..."
This PR adds an error callback to the run function as well as a success callback, and then invokes it from every error path.

This looks great to me.
I wonder if it would be worth adding a special tag for tickets for reports which failed to run as well, doesn't seem like there's much to distinguish successful from failed report tickets just now, just the slightly different summary.
Maybe in the case of failure it would be good to include the report run key in the ticket description so that it would be easier to find in the logs. And possibly an error message as well? Or maybe that would be overkill - since the assignee is just going to re-run and see any persistent error for themselves.

Yeah good shout, some kind of message would be nice. I'll run it by Katy.

I deployed this on prod to see how it works and there's a flaw - when runs are cancelled it still creates tickets! So let me fix that before we merge this.

@EmmaLRussell ok, ready for review :)

LGTM. In the notes for the last Tech call, Kim mentioned setting the Implementer in the tickets as well. Want to do that here or in another branch?

Oh thanks, may as well add it here and then we can get that all deployed


get -> with (a.k.a. Why doesn't get have the with-option?)

I am trying:
$result = $this->get($id)->with('relationtable');
the workaround I have:
$result = $this->where(['id' =>$id])->with('relationtable');
But it gives me an array with 1 record, where the other option gives me an array with record-fields
Why doesn't get have the with-option?

You can use this to get a single record:
$result = $this->where(['id' =>$id])->with('relationtable')->first();

The get method will always return a single entity immediately.


Add exists query

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-exists-query.html

Yeah seems useful, but how about we create an array argument option so we get a cleaner syntax in case of multiple field existence check ?, ex:
instead of
News::search()->exists('body')->exists('tags')->get();

we get
News::search()->exists(['body','tags'])->get();

... like the sortBy method

Good idea. Doneskis. Great package BTW 👍


uv sync produces a large (9.5GB) docker layer upon build

I have the following pyproject.toml:
[project]
name = "cv_tests"
version = "0.1.0"
description = "cv_tests"
authors = [
    {name="me"<EMAIL_ADDRESS>]
readme = "README.md"
requires-python = ">=3.11"
dependencies = [
    "circle-fit>=0.2.1",
    "einops>=0.8.0",
    "fastapi>=0.115.4",
    "imutils>=0.5.4",
    "matplotlib>=3.9.2",
    "open-clip-torch>=2.29.0",
    "opencv-contrib-python>=<IP_ADDRESS>",
    "opencv-python>=<IP_ADDRESS>",
    "pyrealsense2>=<IP_ADDRESS>86",
    "safetensors>=0.4.5",
    "scikit-image>=0.24.0",
    "scikit-learn>=1.5.2",
    "scipy>=1.14.1",
    "shapely>=2.0.6",
    "transformers>=4.46.1",
    "ultralytics>=8.3.27",
    "uvicorn>=0.32.0",
    "xformers>=0.0.28.post3",
    "sam-2",
    "setuptools>=75.3.0",
    "torch-tensorrt>=2.5.0",
    "pre-commit>=4.0.1",
    "lakefs>=0.7.1",
]

[tool.uv.sources]
sam-2 = { git = "https://github.com/facebookresearch/segment-anything-2.git", rev = "c2ec8e14a185632b0a5d8b161928ceb50197eddc" }

and the following Dockerfile:
FROM nvcr.io/nvidia/cuda:12.6.2-cudnn-devel-ubuntu22.04

# https://docs.docker.com/reference/dockerfile/#shell-and-exec-form
# https://manpages.ubuntu.com/manpages/noble/en/man1/sh.1.html
SHELL ["/bin/sh", "-exc"]

ARG DEBIAN_FRONTEND=noninteractive
ARG python_version=3.11

COPY --link --from=ghcr.io/astral-sh/uv:0.5.2 /uv /usr/local/bin/uv

RUN apt-get update --quiet && \
    apt-get upgrade -y && \
    apt-get install --quiet --no-install-recommends -y build-essential git ca-certificates \
    libgl1 libglib2.0-0 libusb-1.0-0-dev && \
    # Forcing http 1.1 to fix https://stackoverflow.com/q/59282476
    git config --global http.version HTTP/1.1 && \
    uv python install $python_version

ENV UV_PYTHON="python$python_version" \
    UV_PYTHON_DOWNLOADS=never \
    UV_PROJECT_ENVIRONMENT=/app \
    UV_LINK_MODE=copy \
    PYTHONFAULTHANDLER=1 \
    PYTHONUNBUFFERED=1 \
    UV_COMPILE_BYTECODE=1 \
    PYTHONOPTIMIZE=1

WORKDIR /project
COPY pyproject.toml uv.lock README.md /project

# Building deps
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --no-dev --no-install-project --frozen

It builds successfully, however when the last RUN command is executed, it creates a huge layer of size 9.5 GB.
I inspected it with dive, to find that it is all taken by /app/lib/python3.11/site-packages

I thought that whenever I do RUN --mount=type=cache,target=/root/.cache/uv, the packages are cached internally in a local docker instance and it is not a part of the current image that I am building. Is there anything I can do about that? I thought of building a base (reusable) image with thick packages like pytorch and then inheriting from it and installing the other packages, so to split the installation in several layers, but then I would need several .toml project configurations and lock files. So I am curious what is the best way to do that? I am not sure if multi-stage build would help me here, but I might be mistaken.

I don't quite follow the issue. uv sync installs the packages. If the layer is big because of installed packages, I'm not sure what we could do differently.
Using a cache mount can speed up installation, but won't remove the installed packages from the image because then it'd be broken.
You could try --no-install-package <big-package> to separate that one out from the rest.

Thank you for the suggestion. I thought that if I use RUN --mount=type=cache,target=/root/.cache/uv, it will mount the packages and cache to the image, but now that I think of it, RUN --mount invokes a temporary mount during build time only, so launching scripts won't work - there will be no packages any longer.


Storage root must match that calculated

#3989  The fix problem is here again，no stop just bucle logs, after stop and start , works well。
Startup script：
./polkadot --rpc-cors=all --pruning=archive  --validator

2019-11-04 07:21:58 Polling the network future took 2.608427841s
2019-11-04 07:22:01 Polling the network future took 1.685406482s
2019-11-04 07:22:02 Syncing  0.0 bps, target=#529139 (6 peers), best: #525501 (0x08ef…8a4a), finalized #525501 (0x08ef…8a4a), ⬇ 26.0kiB/s ⬆ 2.1kiB/s
Hash: given=a6b7f2b73433a191459367d8a4c7ab6e8e8ff9e7e91d9edbfae5ca3a399a8c83, expected=ccbf281d09ad89cffe5b1ed0b933c91d735b41eb9d8f42901637307a171585e1

====================

Version: 0.6.6-ccd1c6eb-x86_64-linux-gnu

stack backtrace:
   0: substrate_panic_handler::set::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:481
   2: std::panicking::begin_panic
   3: srml_executive::Executive<System,Block,Context,UnsignedValidator,AllModules>::execute_block
   4: polkadot_runtime::api::dispatch
   5: std::panicking::try::do_call
   6: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
   7: substrate_executor::native_executor::safe_call
   8: std::thread::local::LocalKey<T>::with
   9: <polkadot_executor::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch
  10: std::thread::local::LocalKey<T>::with
  11: substrate_state_machine::StateMachine<B,H,N,T,Exec>::execute_aux
  12: substrate_state_machine::StateMachine<B,H,N,T,Exec>::execute_call_with_native_else_wasm_strategy
  13: substrate_state_machine::StateMachine<B,H,N,T,Exec>::execute_using_consensus_failure_handler
  14: <substrate_client::call_executor::LocalCallExecutor<B,E> as substrate_client::call_executor::CallExecutor<Block,substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state
  15: <&substrate_client::client::Client<B,E,Block,RA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block
  16: <substrate_finality_grandpa::import::GrandpaBlockImport<B,E,Block,RA,SC> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block
  17: <substrate_consensus_babe::BabeBlockImport<B,E,Block,I,RA,PRA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block
  18: substrate_consensus_common::import_queue::import_single_block
  19: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
  20: <futures_util::future::then::Then<Fut1,Fut2,F> as core::future::future::Future>::poll
  21: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
  22: futures_executor::thread_pool::PoolState::work
  23: std::sys_common::backtrace::__rust_begin_short_backtrace
  24: std::panicking::try::do_call
  25: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  26: core::ops::function::FnOnce::call_once{{vtable.shim}}
  27: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
  28: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
      std::sys_common::thread::start_thread
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:79
  29: start_thread
  30: __clone

Thread 'import-queue-worker-0' panicked at 'Storage root must match that calculated.', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/595f18e/srml/executive/src/lib.rs:271

This is a bug. Please report it at:

	https://github.com/paritytech/polkadot/issues/new

Hash not equal
a6b7f2b73433a191459367d8a4c7ab6e8e8ff9e7e91d9edbfae5ca3a399a8c83
ccbf281d09ad89cffe5b1ed0b933c91d735b41eb9d8f42901637307a171585e1
panicked at 'Storage root must match that calculated.', /Users/gav/.cargo/git/checkouts/substrate-7e08433d4c370a21/595f18e/srml/executive/src/lib.rs:271:3
2019-11-04 07:22:05 Block import error:
Execution(Wasmi(Trap(Trap { kind: Unreachable })))
2019-11-04 07:22:05 Polling the network future took 3.215362915s
2019-11-04 07:22:09 Polling the network future took 2.293160164s
2019-11-04 07:22:10 Syncing  0.0 bps, target=#529139 (5 peers), best: #525501 (0x08ef…8a4a), finalized #525501 (0x08ef…8a4a), ⬇ 21.9kiB/s ⬆ 1.3kiB/s
2019-11-04 07:22:12 Libp2p => Query for [18, 32, 236, 236, 2, 232, 31, 46, 63, 98, 32, 80, 91, 95, 231, 198, 233, 103, 218, 189, 217, 11, 141, 24, 75, 227, 93, 155, 193, 187, 197, 103, 118, 19] timed out with 4 results
2019-11-04 07:22:13 Polling the network future took 2.917068732s

We forgot to include the fix in version 0.6.6. Now, it should be fixed at 0.6 (and starting from the upcoming release 0.6.7).
Please open a new issue if the problem persist in those versions.

The used version is from yesterday: https://github.com/paritytech/polkadot/commit/ccd1c6ebce4b396e7ee202f7f011cdbb937349ab
It should already contain the fix. I think there are maybe more bugs in the code.

But substrate hash is 595f18e right? And doesn't include the fix.

@marcio-diaz ahh! Good catch! :) I didn't checked this at 4am on my mobile. Will close again.


Use GITHUB_TOKEN for API unit test

(cherry picked from commit c988b09d76b7c4521707a097006386fcd3c26dcf)

@SchrodingersGat what purpose does this serve? I seem to be slow to understand today

GitHub seem to have changed the rate limiting on their API and the unit tests have been throwing 403 errors every so often. By authenticating with the token the rate limit restrictions are lifted


fix regression in macro paradise

(the spray-json-shapeless and pcplod freezes are unrelated, but are
presently needed for extraction to succeed)

test run: https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/961/consoleFull
I'll make a separate PR that unfreezes spray-json-shapeless and pcplod; @fommil says that the offending plugin is already on its way to Maven Central


electrumx crashed with general protection fault ip:50fcc4 sp:7ffcc2465108 error:0 in python3.7[421000+232000]

Electrumx has been running for 2d 11h and crashed. Dmesg:
[Tue Sep 15 08:43:16 2020] traps: electrumx_serve[3171321] general protection fault ip:50fcc4 sp:7ffcc2465108 error:0 in python3.7[421000+232000]
Electrumx log has nothing interesting:
2020-09-15 08:43:12,097:INFO:ElectrumX:[2771418] disconnected whilst throttled 2020-09-15 08:43:12,099:INFO:ElectrumX:[2771413] disconnected whilst throttled 2020-09-15 08:43:12,099:INFO:ElectrumX:[2771415] disconnected whilst throttled 2020-09-15 08:43:12,107:INFO:ElectrumX:[2771414] disconnected whilst throttled 2020-09-15 08:43:12,167:INFO:ElectrumX:[2771412] disconnected whilst throttled 2020-09-15 08:43:12,175:INFO:ElectrumX:[2771425] SSL <IP_ADDRESS>:54000, 283 total
System:
OS: Debian GNU/Linux 10 (buster) x86_64
Kernel: 5.7.0-0.bpo.2-amd64
Electrum straight from git, latest commit:

commit 9ca59facfdb50daf063a5813fc9b08eb6fa1b246 (HEAD -> master, origin/master, origin/HEAD)
Merge: 148df48 23633c2
Author: ghost43<EMAIL_ADDRESS>Date:   Mon Aug 24 17:30:54 2020 +0000

Another crash today. Dmesg:
[Mon Sep 28 11:46:31 2020] electrumx_serve[2953515]: segfault at 20008 ip<PHONE_NUMBER>50fc10 sp 00007ffda68f3138 error 4 in python3.7[421000+232000]
Electrumx log shows nothing interesting again.

Another crash today after less than 24h uptime. This time I attached python electrumx_server process to gdb debugger.
Output:
(gdb) continue
Continuing.
Thread 1 "electrumx_serve" received signal SIGSEGV, Segmentation fault.
0x000000000050fcc0 in ?? ()
(gdb) continue
Continuing.
Couldn't get registers: No such process.

The program no longer exists.
(gdb)

Dmesg didn't register anything as error has been caught by gdb as I understand.

And another one:
[Wed Sep 30 02:52:33 2020] electrumx_serve[2406972]: segfault at 2c ip<PHONE_NUMBER>541c7c sp 00007ffe29395cc0 error 4 in python3.7[421000+232000]
[Wed Sep 30 02:52:33 2020] Code: 8b 0d 18 1d 36 00 85 c9 0f 85 80 6e 00 00 8b 05 06 1d 36 00 48 89 ea 48 2b 54 24 10 89 d1 41 89 55 68 85 c0 0f 85 d6 49 00 00 <0f> b7 4d 00 48 83 c5 02 44 0f b6 f9 0f b6 dd 41 81 ff a1 00 00 00

While electrumx crashes very often, bitcoind continues to run and uptime is 25 days.

electrumx died again.

Thread 1 "electrumx_serve" received signal SIGPIPE, Broken pipe.
__libc_send (flags=0, len=79606, buf=0x18e9f160, fd=267) at ../sysdeps/unix/sysv/linux/send.c:28
28	../sysdeps/unix/sysv/linux/send.c: No such file or directory.
(gdb)

Another one after 7 days uptime:
[Wed Oct  7 07:17:59 2020] electrumx_serve[3848664]: segfault at 0 ip<PHONE_NUMBER>000000 sp 00007ffd540d52c8 error 14 in python3.7[400000+21000]
Bitcoind uptime 32 days.


ARROW-16590: [C++] Consolidate files dealing with row-major storage, add some helper methods

This PR is the second PR in a series to merge in #12326.  The first was #12872.  Some of this is new functionality (from michalursa)  and can be found in 7daafeb02906b59c153127463a0c6bed4c888026.  The new behavior is mostly in RowTable and RowTableMerge.  In addition to these new types this PR moves around, and renames, a lot of existing work revolving around KeyRowArray.
The primary goal of this refactor of old code was to improve the readability and clarity of the code base.  I did not make any functional changes to the code and if any functional changes are suggested which modify existing code I will happily discuss them here but defer the changes themselves to follow-up PRs.  I would very much appreciate any feedback on naming, making sure we have sufficient test coverage, and overall layout of the code.
It's a very large change but most of it is moving things around.  What I'd like input on most:

KeyRowArray -> RowTableImpl, RowArray -> RowTable: This is the most meaningful name change.  The old name made sense because this data is currently represented physically as an array of rows.  However, the data is conceptually tabular.  We are storing rows & columns.  In particular, I found it confusing that KeyColumnArray was a 1D data structure while KeyRowArray was a 2D table structure.
Overall structure: I created a new folder arrow/compute/row and put all row-based utilities in here.  Most of the files are now marked as _internal and the content in these files is not used outside of arrow/compute/row.  The grouper had previously been alongside the kernel code and it didn't really belong there.  It also relies very heavily on the internal structure of the row encoding.
Row structure: I documented the file arrow/compute/row/row_internal.h and would appreciate review of the content here.
Semi-external API: The "external" API now consists of arrow/compute/row/grouper.h, which is more or less unchanged, and arrow/compute/encode.h which is mostly new code from 7daafeb02906b59c153127463a0c6bed4c888026.  We have quite a few tests exercising Grouper and I was unable to easily extract them from the aggregate kernel tests so I left the tests alone.  I added tests to the new utilities in encode.h.  These utilities are not yet properly external because they depend on RowTableImpl and I would need to migrate them to the PIMPL pattern to remove this dependency.  Since that would be a functional change I think it would be best to wait.

I'm still chasing a few things around with lint/format and there is a, possibly legitimate and existing, bug with big endian architectures, but I think this is close enough to start review.

CC @michalursa

Per an offline request from @bkietz I've split this PR in two.  The first PR is #13218 and contains only the refactoring.  The changes & new utilities will be put into a future PR.

The second half of this PR has been moved to #13320


docs for autoComplete, autoCorrect and autoCapitalize

Summary
Documentation for autoComplete, autoCorrect and autoCapitalize
Addresses #1036

We ended up releasing these three props in v0.10.1, so I'll add this to my queue for merging.
Thanks again for your help with the docs!


Controller APIs for VC parsing/encoding

Build REST/JS Controller APIs for VC Parsing and encoding.

We should also fix the naming conventions of the Go functions (e.g., Parse instead of New where appropriate).

@troyronda created a new issue https://github.com/hyperledger/aries-framework-go/issues/1313 as changing close to 0.1.2 release(end of feb) might break the consumers. We can do this after 0.1.2 release.

Ok. Let's get the naming right in the controller APIs now and then adjust the underlying Go library in 0.1.3.