My company software is running on multiple vending machines using Android 4.2. I noticed that the certificate generated by Cert manager is not compatible with that device. However if I use traefik with ACME the cert works

i'm sure i used "DST Root CA X3" https://letsencrypt.org/docs/certificate-compatibility/#platforms-that-trust-dst-root-ca-x3

Config

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cloudflare-issuer
spec:
  acme:
    email: {{ .Values.LETENSCRIPT_EMAIL }}
    preferredChain: "DST Root CA X3"
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: cloudflare-issuer
    solvers:
    - dns01:
        cloudflare:
          email: {{ .Values.LETENSCRIPT_EMAIL }}
          apiTokenSecretRef:
            name: cloudflare-api-token-secret
            key: api-token

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: "cloudflare-issuer"
    kubernetes.io/ingress.class: "nginx"
  name: argocd-ingress
  namespace: argocd
spec:
  tls:
  - hosts:
    - {{ .Values.ARGOCD_ADMIN_HOST }}
    secretName: argocd-host-cert
  rules:
  - host: {{ .Values.ARGOCD_ADMIN_HOST }}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 80

Demo cert domain: test.thuongptit.tech

kind: Secret
apiVersion: v1
metadata:
  name: argocd-host-cert
  namespace: argocd
data:
  tls.crt: >-
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUZMekNDQkJlZ0F3SUJBZ0lTQS9xNnVIdkJHZXR5dmx6T2U1dkdrMWtpTUEwR0NTcUdTSWIzRFFFQkN3VUEKTURJeEN6QUpCZ05WQkFZVEFsVlRNUll3RkFZRFZRUUtFdzFNWlhRbmN5QkZibU55ZVhCME1Rc3dDUVlEVlFRRApFd0pTTXpBZUZ3MHlNVEExTVRRd01URTFNVEJhRncweU1UQTRNVEl3TVRFMU1UQmFNQjh4SFRBYkJnTlZCQU1UCkZIUmxjM1F1ZEdoMWIyNW5jSFJwZEM1MFpXTm9NSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUIKQ2dLQ0FRRUE1TmNLNSs3cWRMb2FxOXFZYVVEU1ZDMit4Y3lpVitLVitPc2E0a1dHWndxNk83SGM2VndIRW1rTQpPQ3YySHc2ZEpoaHV1ZWhSUm1xTEpQOFVZOGZwN2hJQnloTm52NnlSU2tVZzluWFJaeG1tSk9vc2EyU0JOeVRJCld1M0J1aGFKWVN4S1J1SEpBWndOZlpaZkdQVitUaFVrVXFOblhRN3MwOEpubUtiM3dXbHJWeEFmQVo0V3VHbWkKWUdTejBLR0NEOVdtcFhjWEFoRy9yYkFKVythWGtyV3FxQ3RYR0NUMWtJUXorY0F0em4yY2c1WVY0Y2lRU0s1VApzR1dUN2Z4ai9RRzI5RVlmSHFVRVhSWkxxZStRVmdaaXU4YTVTRnBuYUlVaGgrSGV0MGZJQ0xkR3gyWVVvYi9YCk50bktEL1ErNmJpY0EySjZIVXQ1dnhOMWcwajBPUUlEQVFBQm80SUNVRENDQWt3d0RnWURWUjBQQVFIL0JBUUQKQWdXZ01CMEdBMVVkSlFRV01CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RBakFNQmdOVkhSTUJBZjhFQWpBQQpNQjBHQTFVZERnUVdCQlFpUDQ3UStPNnVNMWNadnJWTjZlMXJEbTFCK3pBZkJnTlZIU01FR0RBV2dCUVVMck1YCnQxaFd5NjVRQ1VEbUg2K2RpeFRDeGpCVkJnZ3JCZ0VGQlFjQkFRUkpNRWN3SVFZSUt3WUJCUVVITUFHR0ZXaDAKZEhBNkx5OXlNeTV2TG14bGJtTnlMbTl5WnpBaUJnZ3JCZ0VGQlFjd0FvWVdhSFIwY0RvdkwzSXpMbWt1YkdWdQpZM0l1YjNKbkx6QWZCZ05WSFJFRUdEQVdnaFIwWlhOMExuUm9kVzl1WjNCMGFYUXVkR1ZqYURCTUJnTlZIU0FFClJUQkRNQWdHQm1lQkRBRUNBVEEzQmdzckJnRUVBWUxmRXdFQkFUQW9NQ1lHQ0NzR0FRVUZCd0lCRmhwb2RIUncKT2k4dlkzQnpMbXhsZEhObGJtTnllWEIwTG05eVp6Q0NBUVVHQ2lzR0FRUUIxbmtDQkFJRWdmWUVnZk1BOFFCMwpBRnpjUTVMKzVxdEZSTEZlbXRSVzVoQTMrOVg2Ujl5aGM1U3lYdWIyeHc3S0FBQUJlV2luL0xVQUFBUURBRWd3ClJnSWhBSU1Ed1JwT25iRG5Qbi9iaGdRbFgwYkVxdzFQQkpOaHdqN0VxT1pzVldUaUFpRUF1bDVMd1k1SW1ESzAKZUpIMzB2aENlVjBTN1N4QW1lTjRPemlPZnduQWw3UUFkZ0QyWEpRdjBYY3dJaFJVR0Fnd2xGYU80MDBUR1RPLwozd3d2SUF2TVR2Rms0d0FBQVhsb3AvMVZBQUFFQXdCSE1FVUNJUUN5UWNiWllCaG5wbzkwQ0N5bnBRWUppOHB0ClR2ZFdnS2VBeTl1NkthcmRRZ0lnQU1LQ1BNSG9MczNTNEwrc0pHbHRuWTNIeCt5WDJzb2c3MlByQ05TTG5ZTXcKRFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUZsaWxVRVVVb3FXOG8vd1pyRlNlYlYxdUxQM2xybzdub2hEdFhnVQplaUE0OFZ3VnFGK1pzL2JVN01rSzl3VE56cGFnMlpvbm5BeEpxWkFVRXZBM3ZKMHo3MHJVYnMybVFHM3NiaUhHCnczRlBUeWNPL1Q1WTdwYzZMNTRWT25mVjh4NWVVSjdnSm1SY0xSaDFhdC85YTg5S1o1U3pXenZnQkR1S2sxMXoKRURra2VSODFhcVhXeUJINGVubjlWRzgzclNPdElZRzlGVEJhbWg2ME1FUUt3U1B0VHpOamh4c3BsVGhJbk1QSwo2SHpLQmJrOUFRMEM2R2p1b3paSHRKU2ZPd29DcFlxRHBjVmJpdks1QlRUZnIrVndIdTJWWlJ3c2JyUmRzWk9MCnBablpzaDBIM3pBMjQ0QURMQ1dGb3R3OHdOVEUvZ1FpZkFCRzJidEZuN3pHVGt3PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlGRmpDQ0F2NmdBd0lCQWdJUkFKRXJDRXJQREJpblUvYldMaVduWDFvd0RRWUpLb1pJaHZjTkFRRUxCUUF3ClR6RUxNQWtHQTFVRUJoTUNWVk14S1RBbkJnTlZCQW9USUVsdWRHVnlibVYwSUZObFkzVnlhWFI1SUZKbGMyVmgKY21Ob0lFZHliM1Z3TVJVd0V3WURWUVFERXd4SlUxSkhJRkp2YjNRZ1dERXdIaGNOTWpBd09UQTBNREF3TURBdwpXaGNOTWpVd09URTFNVFl3TURBd1dqQXlNUXN3Q1FZRFZRUUdFd0pWVXpFV01CUUdBMVVFQ2hNTlRHVjBKM01nClJXNWpjbmx3ZERFTE1Ba0dBMVVFQXhNQ1VqTXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUsKQW9JQkFRQzdBaFVvelBhZ2xOTVBFdXlOVlpMRCtJTHhtYVo2UW9pblhTYXF0U3U1eFV5eHI0NXIrWFhJbzljUApSNVFVVlRWWGpKNm9vamtaOVlJOFFxbE9idlU3d3k3YmpjQ3dYUE5aT09mdHoybndXZ3NidnNDVUpDV0gramR4CnN4UG5IS3pobSsvYjVEdEZVa1dXcWNGVHpqVElVdTYxcnUyUDNtQnc0cVZVcTdadERwZWxRRFJySzlPOFp1dG0KTkh6NmE0dVBWeW1aK0RBWFhicHliL3VCeGEzU2hsZzlGOGZuQ2J2eEsvZUczTUhhY1YzVVJ1UE1yU1hCaUx4ZwpaM1Ztcy9FWTk2SmM1bFAvT29pMlI2WC9FeGpxbUFsM1A1MVQrYzhCNWZXbWNCY1VyMk9rLzVtems1M2NVNmNHCi9raUZIYUZwcmlWMXV4UE1VZ1AxN1ZHaGk5c1ZBZ01CQUFHamdnRUlNSUlCQkRBT0JnTlZIUThCQWY4RUJBTUMKQVlZd0hRWURWUjBsQkJZd0ZBWUlLd1lCQlFVSEF3SUdDQ3NHQVFVRkJ3TUJNQklHQTFVZEV3RUIvd1FJTUFZQgpBZjhDQVFBd0hRWURWUjBPQkJZRUZCUXVzeGUzV0ZiTHJsQUpRT1lmcjUyTEZNTEdNQjhHQTFVZEl3UVlNQmFBCkZIbTBXZVo3dHVYa0FYT0FDSWpJR2xqMjZadHVNRElHQ0NzR0FRVUZCd0VCQkNZd0pEQWlCZ2dyQmdFRkJRY3cKQW9ZV2FIUjBjRG92TDNneExta3ViR1Z1WTNJdWIzSm5MekFuQmdOVkhSOEVJREFlTUJ5Z0dxQVloaFpvZEhSdwpPaTh2ZURFdVl5NXNaVzVqY2k1dmNtY3ZNQ0lHQTFVZElBUWJNQmt3Q0FZR1o0RU1BUUlCTUEwR0N5c0dBUVFCCmd0OFRBUUVCTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFDRnlrNUhQcVAzaFVTRnZOVm5lTEtZWTYxMVRSNlcKUFRObGNsUXRnYURxdyszNElMOWZ6TGR3QUxkdU8vWmVsTjdrSUorbTc0dXlBK2VpdFJZOGtjNjA3VGtDNTN3bAppa2ZtWlc0L1J2VFo4TTZVSys1VXpoSzhqQ2RMdU1HWUw2S3Z6WEdSU2dpM3lMZ2pld1F0Q1BrSVZ6NkQyUVF6CkNrY2hlQW1DSjhNcXlKdTV6bHp5Wk1qQXZubkFUNDV0UkF4ZWtyc3U5NHNRNGVnZFJDbmJXU0R0WTdraCtCSW0KbEpOWG9CMWxCTUVLSXE0UURVT1hvUmdmZnVEZ2hqZTFXckc5TUwrSGJpc3EveUZPR3dYRDlSaVg4RjZzdzZXNAphdkF1dkRzenVlNUwzc3o4NUsrRUM0WS93RlZETnZabzRUWVhhbzZaMGYrbFFLYzB0OERRWXprMU9YVnU4cnAyCnlKTUM2YWxMYkJmT0RBTFp2WUg3bjdkbzFBWmxzNEk5ZDFQNGpua0RyUW94QjNVcVE5aFZsM0xFS1E3M3hGMU8KeUs1R2hERFg4b1ZmR0tGNXUrZGVjSXNINFlhVHc3bVAzR0Z4SlNxdjMrMGxVRkpvaTVMYzVkYTE0OXA5MElkcwpoQ0V4cm9MMSs3bXJ5SWtYUGVGTTVUZ085cjBydlphQkZPdlYyejBncDM1WjArTDRXUGxidUVqTi9seFBGaW4rCkhsVWpyOGdSc0kzcWZKT1FGeS85cktJSlIwWS84T213dC84b1RXZ3kxbWRlSG1tams3ajFuWXN2QzlKU1E2WnYKTWxkbFRUS0IzemhUaFYxK1hXWXA2cmpkNUpXMXpiVldFa0xOeEU3R0pUaEVVRzNzemdCVkdQN3BTV1RVVHNxWApuTFJid0hPb3E3aEh3Zz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUZZRENDQkVpZ0F3SUJBZ0lRUUFGM0lUZlU2VUs0N25hcVBHUUt0ekFOQmdrcWhraUc5dzBCQVFzRkFEQS8KTVNRd0lnWURWUVFLRXh0RWFXZHBkR0ZzSUZOcFoyNWhkSFZ5WlNCVWNuVnpkQ0JEYnk0eEZ6QVZCZ05WQkFNVApEa1JUVkNCU2IyOTBJRU5CSUZnek1CNFhEVEl4TURFeU1ERTVNVFF3TTFvWERUSTBNRGt6TURFNE1UUXdNMW93ClR6RUxNQWtHQTFVRUJoTUNWVk14S1RBbkJnTlZCQW9USUVsdWRHVnlibVYwSUZObFkzVnlhWFI1SUZKbGMyVmgKY21Ob0lFZHliM1Z3TVJVd0V3WURWUVFERXd4SlUxSkhJRkp2YjNRZ1dERXdnZ0lpTUEwR0NTcUdTSWIzRFFFQgpBUVVBQTRJQ0R3QXdnZ0lLQW9JQ0FRQ3Q2Q1J6OUJRMzg1dWVLMWNvSEllKzNMZmZPSkNNYmp6bVY2QjQ5M1hDCm92NzFhbTcyQUU4bzI5NW9obXhFazdheFkvMFVFbXUvSDlMcU1ac2hmdEV6UExwSTlkMTUzN080L3hMeElacEwKd1lxR2NXbEtabVpzajM0OGNMK3RLU0lHOCtUQTVvQ3U0a3VQdDVsK2xBT2YwMGVYZkpsSUkxUG9PSzVQQ20rRApMdEZKVjR5QWRMYmFMOUE0alhzRGNDRWJkZkl3UFBxUHJ0M2FZNnZyRmsvQ2poRkxmczhMNlArMWR5NzBzbnRLCjRFd1NKUXh3alFNcG9PRlRKT3dUMmU0WnZ4Q3pTb3cvaWFOaFVkNnNod2VVOUdOeDdDN2liMXVZZ2VHSlhEUjUKYkhidk81QmllZWJicEpvdkpzWFFFT0VPM3RrUWpoYjd0L2VvOThmbEFnZVlqellJbGVmaU41WU5ObldlK3c1eQpzUjJidkFQNVNRWFlnZDBGdENyV1FlbXNBWGFWQ2cvWTM5VzlFaDgxTHlnWGJOS1l3YWdKWkhkdVJ6ZTZ6cXhaClhtaWRmM0xXaWNVR1FTaytXVDdkSnZVa3lSR25XcU5NUUI5R29abTFwenBSYm9ZN25uMXlweElGZUZudFBsRjQKRlFzRGo0M1FMd1d5UG50S0hFdHpCUkw4eHVyZ1VCTjhRNU4wczhwMDU0NGZBUWpRTU5SYmNUYTBCN3JCTURCYwpTTGVDTzVpbWZXQ0tvcU1wZ3N5NnZZTUVHNktEQTBHaDFnWHhHOEsyOEtoOGhqdEdxRWdxaU54Mm1uYS9IMnFsClBSbVA2emp6Wk43SUt3MEtLUC8zMitJVlF0UWkwQ2RkNFhuK0dPZHdpSzFPNXRtTE9zYmRKMUZ1Lzd4azlUTkQKVHdJREFRQUJvNElCUmpDQ0FVSXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQVFZdwpTd1lJS3dZQkJRVUhBUUVFUHpBOU1Ec0dDQ3NHQVFVRkJ6QUNoaTlvZEhSd09pOHZZWEJ3Y3k1cFpHVnVkSEoxCmMzUXVZMjl0TDNKdmIzUnpMMlJ6ZEhKdmIzUmpZWGd6TG5BM1l6QWZCZ05WSFNNRUdEQVdnQlRFcDdHa2V5eHgKK3R2aFM1QjEvOFFWWUlXSkVEQlVCZ05WSFNBRVRUQkxNQWdHQm1lQkRBRUNBVEEvQmdzckJnRUVBWUxmRXdFQgpBVEF3TUM0R0NDc0dBUVVGQndJQkZpSm9kSFJ3T2k4dlkzQnpMbkp2YjNRdGVERXViR1YwYzJWdVkzSjVjSFF1CmIzSm5NRHdHQTFVZEh3UTFNRE13TWFBdm9DMkdLMmgwZEhBNkx5OWpjbXd1YVdSbGJuUnlkWE4wTG1OdmJTOUUKVTFSU1QwOVVRMEZZTTBOU1RDNWpjbXd3SFFZRFZSME9CQllFRkhtMFdlWjd0dVhrQVhPQUNJaklHbGoyNlp0dQpNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUFLY3dCc2xtNy9EbExRcnQyTTUxb0dyUytvNDQrL3lRb0RGVkRDCjVXeEN1MitiOUxSUHdrU0lDSFhNNndlYkZHSnVlTjdzSjdvNVhQV2lvVzVXbEhBUVU3Rzc1Sy9Rb3NNckFkU1cKOU1VZ05UUDUyR0UyNEhHTnRMaTFxb0pGbGNEeXFTTW81OWFoeTJjSTJxQkRMS29ia3gvSjN2V3JhVjBUOVZ1RwpXQ0xLVFZYa2NHZHR3bGZGUmpsQno0cFlnMWh0bWY1WDZEWU84QTRqcXYySWw5RGpYQTZVU2JXMUZ6WFNMcjlPCmhlOFk0SVdTNndZN2JDa2pDV0RjUlFKTUVoZzc2ZnNPM3R4RStGaVlydXE5UlVXaGlGMW15djRRNlcrQ3lCRkMKRGZ2cDdPT0dBTjZkRU9NNCtxUjlzZGpvU1lLRUJwc3I2R3RQQVF3NGR5NzUzZWM1Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  tls.key: >-
    LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBNU5jSzUrN3FkTG9hcTlxWWFVRFNWQzIreGN5aVYrS1YrT3NhNGtXR1p3cTZPN0hjCjZWd0hFbWtNT0N2Mkh3NmRKaGh1dWVoUlJtcUxKUDhVWThmcDdoSUJ5aE5udjZ5UlNrVWc5blhSWnhtbUpPb3MKYTJTQk55VElXdTNCdWhhSllTeEtSdUhKQVp3TmZaWmZHUFYrVGhVa1VxTm5YUTdzMDhKbm1LYjN3V2xyVnhBZgpBWjRXdUdtaVlHU3owS0dDRDlXbXBYY1hBaEcvcmJBSlcrYVhrcldxcUN0WEdDVDFrSVF6K2NBdHpuMmNnNVlWCjRjaVFTSzVUc0dXVDdmeGovUUcyOUVZZkhxVUVYUlpMcWUrUVZnWml1OGE1U0ZwbmFJVWhoK0hldDBmSUNMZEcKeDJZVW9iL1hOdG5LRC9RKzZiaWNBMko2SFV0NXZ4TjFnMGowT1FJREFRQUJBb0lCQUhIRDZwc1ZicCtyS2JsSQpDajlCUjQ4cjBzeTVCL2hUSUNYSWsrdnJqbjdKbVg0MTFWSjZPdFhQUFpEcllnZGNsNG1wMmRvNGdiZFZIbW05CkdpRGs4UW8zRDRhcmtRZDhQaHJETlRqeHA3SHUwV2RHdCtDSDdhbEJjdzJwWjRjZ3p4bHRFRndld1hRNFpZaUsKNmlvWldicHR6a243REZiNkpZaTgvQTJxN0Q3TlBnNEoyckZneWhwMnBpQlhYZityckR3Vk9SNFp4aEhHNUoxSgo1b1ZHdmRhQWhLM3o4REpla0F0WXFlL2hka29pNlpyVTRROW40S2ZzeVphd1VsK2xXaldqZFVBNHVRbUg1NFQzCk9YeFZ5d1FyOHhOVDBvZnNMQ2IwMUlpQ09yRUlzVFEzUWlXa280ZytlbGNaNDNDS3R6ZjhQTzdMMXFnaGhUSysKclJpZk5iVUNnWUVBK3J2OVIwTm1tTXlkdmZmME9ZMTdQa1kyZE00VlJHR2VkaEdzd2ZsVVNFTit6QmVSaDB1SwpoTXBIbVJ4VGlQT3cwVk5EZlhvQmZWa1M1VHRQOTJqazlWT3NSSkh0UTdpT2doMFdrcHpLVFU3cTBFRFFGOEt0ClQ4bHBDQktIWml2dEg1RWRkdGFOWThaYTVwRlRvTCt5TEVoanlQcHdXbWRGQ0djVHF2SE9hSU1DZ1lFQTZhVlkKQjF0UUNOQTBFMjhwVDV6RDJERHJNSGE0MDJSM3UxSEZ5ZTd3MnpVY0JQbkdPbU8xcmIxOFo0Rk5RcW9uVWZXNgpCYmpwdTNJdlQzamRVQ1dVY1pXZlVJV0VTbFdtbkt6ZFI5U2VIdVJpNmphVTd4TjgzUU02WnIrWFp5bHUxWGVHCngyaVVDallyaVozWWZJRHUzNDlSbUh0VnNrWTB1azRQaGQ2RWU1TUNnWUFaekRQUUhFQTNJbjVzYUZHcGhrUVMKOFRoekppMEwveHRGdktYUXcyMkhqZUpDNzMzYXRNd0l3Nk5BUHFqZG8yMGk3SFU2T001a2JrRENjeXJVSXVmRAowaHNjWndOSmYzaXlMSG9CRmI2KzI0clBhSXZBbGhnczZHVTFIbXJ0K1VFSmlXM0ZwMmVleDI3YzRFRUJmaGUvCjlLYkhxL1RaYUZ5eTg2QVRhNU80THdLQmdFQnVtWFVGNkc5VncxYXNyQTdKWTNUR0lNV3ZwODZjQVN6R0l5NUoKMTJBTUtGcnk2b2lGb0w5MTVzM0FhYWI5dDNReHVJZ0ZjMmQrMks4bzNKZFNsYm94RWNzcDFzNk5DakpndFhFdQpvQ0JTeVRoZnJ2aXpQaGJRNGhVZHRzbjdNaFpxTE4vbTVoUmUxZWpRZjdmdDhuSHlXd1VhMWdvZ3REL0FjU1Z3CnRNWkRBb0dBQ1l3b01Vd2tQUnBKVk5yUlhaclZGMTUrbVU2RDdsMk0xT3VPbFRHeTAxOFFDMGoxaFVTTFAzMkMKOVZPVy9BWEIzMTRacUhPQk9iUTJoQ2FudDdXWEMvazFHNGRBeWlTMW5mdXhQUElaZHNxVWpob2FOUEJiZjlwVgozK0ZSSWlrT0duZ3F1VU1RRTI0WDd2RVU2ZTVVU3JjL29BbXJUcU8xZVRQaTN6T0dGeFE9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
type: kubernetes.io/tls

Error in android 4.2.2.

Note this is not a browser issue. Our application running on android 4.2.2 has encountered a problem connecting to the server. But when we switched to traefik everything worked again.

I think the default configurations of Cert manager should be compatible with as many devices as possible.

Sorry. I see this is a problem of ssl protocol. https://kubernetes.github.io/ingress-nginx/user-guide/tls/#legacy-tls

@irbekrm, here are the logs during the time that the certs are being issued on crt.sh, and thanks for all the help. log-events-viewer-result.csv

Thanks for the logs! Did you also have a chance to check if the Secret www-wefixlocksnow-com-cert was really not there at that point? In that case, I wonder if it's somehow related to cert-manager failing to create the Secret.

From the logs I just see that cert-manager attempts to re-issue as it does not find the Secret, but the re-issuance fails. If I understand correctly the logs are from around 11pm UTC 10th of May? Looking at crt.sh it appears that there should have been a successful issuance around 10am UTC on that day- so I guess we would need to look at the controller logs from around that point in time, to see why the Secret was not created (if it is the case that the Secret was not there?).

Appreciate that parsing logs of that size is not trivial and I'm sorry you had to go through the downgrade process once again. I have tried to reproduce this issue with cert-manager v1.3.1 with pebble with a few hundred certs with a short renewal time, but did not see anything abnormal during creation or renewal- if you have any suggestions how to reproduce this, do let us know.

I'm kind of surprised that no one else seems to be having these kinds of issues - 14k certs probably isn't the most common use case, but certainly we're not the only ones?

There are users with large cert-manager deployments, 14k won't be the largest, unfortunately we don't have any data as to who is using which versions at the moment. It may be worth to enquire on #cert-manager channel in Kubernetes Slack.

While clang cannot build an m68k kernel yet, this will eventually be needed so why not now? :)

I have verified that this works with GCC 10.3.0 and mac_defconfig. I believe there will eventually be a virt machine too.

@Nymria could you elaborate a bit on what exactly your issue was?

I know this is closed, but if the message is "benign", then it shouldn't really be an error (make it info, or even debug). For operations people, error messages are serious business. Error messages indicate "some action needs to be taken", but if this is just informational, please re-categorize this (and other) messages accordingly.

While clang cannot build an m68k kernel yet, this will eventually be needed so why not now? :)

@nickdesaulniers yay :) I can boot 5.13-rc1 on Real hardware now with LLVM=1, so when my patch is accepted, we need to update https://www.kernel.org/doc/html/latest/kbuild/llvm.html#supported-architectures to reflect that RISCV can build with LLVM=1 too

As far as I can tell, it is possible for the output_artifacts to get overridden, resulting in builds that cannot be found:

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/836619133

Normally, defconfigs finish first but it is possible for a cached allmodconfig to beat LTO'd defconfigs. To avoid this race, cache the builds.json under a slightly more descriptive name using the build set name as a suffix.

Changes:

• Change flag from disable_access_logger to access_log_level
• Add a simple check in validateConfig that a supported log level is supplied
• Change the logging instantiation business logic to instead discard the output when the level is "none"

I didn't create constants for "none" and "all" since there doesn't seem to be a convention for that (see e.g. "zstd"/"uncompressed") but I can do that if needed.

Additional manual verification:

$ bazelisk run //:bazel-remote -- --dir /tmp/bazel --max_size 1 --port 8080 --access_log_level invalid
...
2021/05/14 18:37:07 bazel-remote built with go1.16.2 from git commit ec16031f6133df98481eb48df8137d1204ba2b63.
'access_log_level' must be set to either "none" or "all"
...

Will open for acceptance when this CL has been merged:

https://android-review.googlesource.com/c/kernel/common/+/1702384

Traceback (most recent call last):
  File "./check_logs.py", line 102, in <module>
    build = get_build()
  File
"/home/runner/work/continuous-integration2/continuous-integration2/utils.py",
line 74, in get_build
    llvm_version = get_requested_llvm_version()
  File
"/home/runner/work/continuous-integration2/continuous-integration2/utils.py",
line 64, in get_requested_llvm_version
    ver = int(os.environ["LLVM_VERSION"])
ValueError: invalid literal for int() with base 10: 'android'

from the initial log:

general protection fault, maybe for address 0xffffb80d81b6b5d8: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dcn30_update_bw_bounding_box+0x33/0x530 [amdgpu]
RSP: 0018:ffffb80d81b6b5d8 EFLAGS: 00010296

so some bad stack access in dcn30_update_bw_bounding_box perhaps? @aruhier can you provide the output of llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinux in another file attachment?

Sorry, I'm really not used to tweak with LLVM binaries, so I'm probably not going to be able to adapt too much the commands you give me. So:

llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinuz-5.12.3-x86_64
vmlinuz-5.12.3-x86_64:	file format coff-x86-64

llvm-objdump: warning: 'vmlinuz-5.12.3-x86_64': failed to disassemble missing symbol dcn30_update_bw_bounding_box

Which is probably not what you want. However I executed it on the amdgpu module: amdgpu.log

Since 5.1 kernel, klp_patch supports a "replace" option, which does atomic replace of cumulative patches. Enable building such patch with an option.

Signed-off-by: Song Liu [email protected]

Your build command is a little odd:

COMMAND: nice -n15 make -j30 ARCH='x86' AS='/usr/lib/llvm/12/bin/llvm-as' AR='/usr/lib/llvm/12/bin/llvm-ar' CC='/usr/lib/llvm/12/bin/clang' LD='ld.lld' NM='/usr/lib/llvm/12/bin/llvm-nm' OBJCOPY='x86_64-pc-linux-gnu-objcopy' OBJDUMP='x86_64-pc-linux-gnu-objdump' READELF='x86_64-pc-linux-gnu-readelf' STRIP='x86_64-pc-linux-gnu-strip' HOSTAR='x86_64-pc-linux-gnu-ar' HOSTCC='x86_64-pc-linux-gnu-gcc' HOSTCXX='x86_64-pc-linux-gnu-g++' HOSTLD='ld.lld' bzImage

I do not see LLVM_IAS=1 anywhere, which is a little odd, since that is a dependency of HAS_LTO_CLANG. I guess genkernel does not have support for that explicitly but I am guessing you could add LLVM_IAS=1 to your MAKEOPTS. AS='/usr/lib/llvm/12/bin/llvm-as' does not work for selecting the integrated assembler for two reasons:

1. `$(AS)` was removed in commit [aa824e0c962b](https://git.kernel.org/linus/aa824e0c962b532d5073cbb41b2efcd6f5e72bae) ("kbuild: remove AS variable").

2. `llvm-as` converts LLVM IR to LLVM bitcode (`.ll` -> `.bc`), it will not work in this context.

I have no idea if this is actually related to your issue, just a general observation.

It may be worth reporting this to [email protected] to see if anyone else can reproduce it.

cc @samitolvanen

I do, I export LLVM=1 LLVM_IAS=1. Without it, I cannot enable LTO.

that someone is @kraj, who has given talks on Linux and LLVM before. ;)

@irbekrm FYI: I work with @atenciom, and this is the same cluster as the one for #3603, which currently hosts around 14k certs.

We've noticed that once the cluster gets in this state, we get some pretty bad throughput. We had about 5k certs queued, with the following being completed within cert-manager (cert count grouped by status.notAfter date):

   5 2021-08-10
 335 2021-08-08
   4 2021-08-07
   5 2021-08-06
   9 2021-08-05
  20 2021-08-04
  57 2021-08-03
 273 2021-08-02
 232 2021-08-01
  81 2021-07-31
   3 2021-07-29
   1 2021-07-28
  10 2021-07-27

That's 1,035 over a period of 15 days, or roughly 70 per day. Yesterday, we reverted the cluster back to 0.14.3 yesterday to try to get us caught up. It took most of the day to get reverted (remove CRDs, re-create resources, etc), but even with a partial day we had over 300 certs complete. Since then, we've had nearly 2,400 more issued:

2379 2021-08-12
 307 2021-08-11

So, I think that excludes any potential issue with letsencrypt rate limiting, and that there's something odd going on in 1.3.1. I'm kind of surprised that no one else seems to be having these kinds of issues - 14k certs probably isn't the most common use case, but certainly we're not the only ones?

This is in AWS EKS, and we do have the logs in CloudWatch via ContainerInsights going back for months, but they're several hundred GBs of them and distinguished by pod ID, so it's non-trivial to search for the exact ones you're asking for. If you have some kind of filter that we could apply to for search criteria, that would help a lot. Or, if you think having access to the raw logs could be beneficial, please let us know and we can chat about some better ways to share them with you.

This issue is more of an FYI than anything else.

With an assertions build of LLVM 10 and LLVM 11, I get a crash while building x86_64 defconfig:

$ make -skj"$(nproc)" LLVM=1 defconfig kernel/softirq.o
clang-10: /home/nathan/cbl/github/tc-build/llvm-project/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1548: void (anonymous namespace)::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *, (anonymous namespace)::TwoAddressInstructionPass::TiedPairList &, unsigned int &): Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed.
Stack dump:
0.      Program arguments: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name softirq.c -mrelocation-model static -mthread-model posix -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -no-integrated-as -mconstructor-aliases -mcode-model kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1 -dependency-file kernel/.softirq.o.d -MT kernel/softirq.o -isystem /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D KBUILD_MODFILE="kernel/softirq" -D KBUILD_BASENAME="softirq" -D KBUILD_MODNAME="softirq" -D __KBUILD_MODNAME=kmod_softirq -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-sign-compare -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/nathan/cbl/src/linux -ferror-limit 19 -fmessage-length 0 -fwrapv -stack-protector 2 -mstack-alignment=8 -fcf-protection=none -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/softirq-0ff896.s -x c kernel/softirq.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'kernel/softirq.c'.
4.      Running pass 'Two-Address instruction pass' on function '@do_softirq'
 #0 0x00000000033bfd7f llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33bfd7f)
 #1 0x00000000033c025f SignalHandler(int) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33c025f)
 #2 0x00007f625b3d4960 __restore_rt (/usr/lib/libpthread.so.0+0x13960)
 #3 0x00007f625aec6ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #4 0x00007f625aeb0862 abort (/usr/lib/libc.so.6+0x26862)
 #5 0x00007f625aeb0747 _nl_load_domain.cold (/usr/lib/libc.so.6+0x26747)
 #6 0x00007f625aebf646 (/usr/lib/libc.so.6+0x35646)
 #7 0x0000000002cafc86 (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2cafc86)
 #8 0x0000000002a0bfb7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2a0bfb7)
 #9 0x0000000002dd00a7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd00a7)
#10 0x0000000002dd0766 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0766)
#11 0x0000000002dd0b6e llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0b6e)
#12 0x000000000359b67a clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x359b67a)
#13 0x0000000003d31e6c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d31e6c)
#14 0x0000000004593029 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x4593029)
#15 0x0000000003c8f9d2 clang::FrontendAction::Execute() (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3c8f9d2)
#16 0x0000000003bc1bf8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3bc1bf8)
#17 0x0000000003d2c348 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d2c348)
#18 0x0000000001e349fe cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e349fe)
#19 0x0000000001e32b5f ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e32b5f)
#20 0x0000000001e30a0b main (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e30a0b)
#21 0x00007f625aeb1b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#22 0x0000000001e2f86e _start (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e2f86e)
clang-10: error: unable to execute command: Aborted (core dumped)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 10.0.1 (https://github.com/llvm/llvm-project ef32c611aa214dea855364efd7ba451ec5ec3f74)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin

When I bisected Linux, I ended up with https://git.kernel.org/linus/569dd8b4eb7ef666b467c41b8e8e4f2820d07f67 and when I bisected LLVM for the fix, I ended up with https://github.com/llvm/llvm-project/commit/42a82862b625279028130e62846d057425bca691 (ended up in llvmorg-12.0.0), which seems to make sense.

I do not think there is really anything that we can do about this now, other than say do not use assertions with these versions or upgrade your compiler :)

This issue is more of an FYI than anything else.

With an assertions build of LLVM 10 and LLVM 11, I get a crash while building x86_64 defconfig:

$ make -skj"$(nproc)" LLVM=1 defconfig kernel/softirq.o
clang-10: /home/nathan/cbl/github/tc-build/llvm-project/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1548: void (anonymous namespace)::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *, (anonymous namespace)::TwoAddressInstructionPass::TiedPairList &, unsigned int &): Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed.
Stack dump:
0.      Program arguments: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name softirq.c -mrelocation-model static -mthread-model posix -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -no-integrated-as -mconstructor-aliases -mcode-model kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1 -dependency-file kernel/.softirq.o.d -MT kernel/softirq.o -isystem /home/nathan/cbl/usr/stow/llvm/10.0.1/lib/clang/10.0.1/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D KBUILD_MODFILE="kernel/softirq" -D KBUILD_BASENAME="softirq" -D KBUILD_MODNAME="softirq" -D __KBUILD_MODNAME=kmod_softirq -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-sign-compare -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/nathan/cbl/src/linux -ferror-limit 19 -fmessage-length 0 -fwrapv -stack-protector 2 -mstack-alignment=8 -fcf-protection=none -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/softirq-0ff896.s -x c kernel/softirq.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'kernel/softirq.c'.
4.      Running pass 'Two-Address instruction pass' on function '@do_softirq'
 #0 0x00000000033bfd7f llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33bfd7f)
 #1 0x00000000033c025f SignalHandler(int) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x33c025f)
 #2 0x00007f625b3d4960 __restore_rt (/usr/lib/libpthread.so.0+0x13960)
 #3 0x00007f625aec6ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #4 0x00007f625aeb0862 abort (/usr/lib/libc.so.6+0x26862)
 #5 0x00007f625aeb0747 _nl_load_domain.cold (/usr/lib/libc.so.6+0x26747)
 #6 0x00007f625aebf646 (/usr/lib/libc.so.6+0x35646)
 #7 0x0000000002cafc86 (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2cafc86)
 #8 0x0000000002a0bfb7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2a0bfb7)
 #9 0x0000000002dd00a7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd00a7)
#10 0x0000000002dd0766 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0766)
#11 0x0000000002dd0b6e llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x2dd0b6e)
#12 0x000000000359b67a clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x359b67a)
#13 0x0000000003d31e6c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d31e6c)
#14 0x0000000004593029 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x4593029)
#15 0x0000000003c8f9d2 clang::FrontendAction::Execute() (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3c8f9d2)
#16 0x0000000003bc1bf8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3bc1bf8)
#17 0x0000000003d2c348 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x3d2c348)
#18 0x0000000001e349fe cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e349fe)
#19 0x0000000001e32b5f ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e32b5f)
#20 0x0000000001e30a0b main (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e30a0b)
#21 0x00007f625aeb1b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#22 0x0000000001e2f86e _start (/home/nathan/cbl/usr/stow/llvm/10.0.1/bin/clang-10+0x1e2f86e)
clang-10: error: unable to execute command: Aborted (core dumped)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 10.0.1 (https://github.com/llvm/llvm-project ef32c611aa214dea855364efd7ba451ec5ec3f74)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/cbl/usr/stow/llvm/10.0.1/bin

When I bisected Linux, I ended up with https://git.kernel.org/linus/569dd8b4eb7ef666b467c41b8e8e4f2820d07f67 and when I bisected LLVM for the fix, I ended up with https://github.com/llvm/llvm-project/commit/42a82862b625279028130e62846d057425bca691 (ended up in llvmorg-12.0.0), which seems to make sense.

I do not think there is really anything that we can do about this now, other than say do not use assertions with these versions or upgrade your compiler :)

Arnd sent a patch: https://lore.kernel.org/r/[email protected]/

Someone sent a patch equivalent to mine above: https://lore.kernel.org/r/[email protected]/

Fixed: https://git.kernel.org/linus/2c475caf72f37c565c03c2f6b9b9e86ec29932e2