hush debug on aarch64 platform

hush_tx_with_cc.txt

{
  "hex": "0400008085202f890106ffbcbdb58c2ac258ff48674d168e27ad36b6ca5b2d8324945f6226517f3b0c000000007b4c79a276a072a26ba067a565802103682b255c40d0cde8faee381a1a50bbb89980ff24539cb8518e294d3a63cefe1281401a84c402a44b22ee5903e2aca164da48594be0f52e9a841d004d38a53a05acfd00b6111caba5ed6209d3bcfc5c3403e60804ae5de2e8ff8bdb4bd1dd37d5f465a100af038001e4a10001ffffffff03706f980000000000302ea22c8020e029c511da55523565835887e412e5a0c9b920801b007000df45e545f25028248103120c008203000401cc8096980000000000232102a55f6295cce69932aaedd3e12b4caec263ce1147d5417d7628ebc3e20f970d21ac0000000000000000086a06e4470b4a8b0b00000000bab202000000000000000000000000",
  "txid": "0066ddbbb664b96e3762fd069e4258fd0579d7e1dd9b60cc7407460c592d2400",
  "overwintered": true,
  "version": 4,
  "last_notarized_height": 260906,
  "versiongroupid": "892f2085",
  "locktime": 0,
  "expiryheight": 176826,
  "vin": [
    {
      "txid": "0c3b7f5126625f9424832d5bcab636ad278e164d6748ff58c22a8cb5bdbcff06",
      "vout": 0,
      "address": "R9zHrofhRbub7ER77B7NrVch3A63R39GuC",
      "scriptSig": {
        "asm": "a276a072a26ba067a565802103682b255c40d0cde8faee381a1a50bbb89980ff24539cb8518e294d3a63cefe1281401a84c402a44b22ee5903e2aca164da48594be0f52e9a841d004d38a53a05acfd00b6111caba5ed6209d3bcfc5c3403e60804ae5de2e8ff8bdb4bd1dd37d5f465a100af038001e4a10001",
        "hex": "4c79a276a072a26ba067a565802103682b255c40d0cde8faee381a1a50bbb89980ff24539cb8518e294d3a63cefe1281401a84c402a44b22ee5903e2aca164da48594be0f52e9a841d004d38a53a05acfd00b6111caba5ed6209d3bcfc5c3403e60804ae5de2e8ff8bdb4bd1dd37d5f465a100af038001e4a10001"
      },
      "value": 0.20000000,
      "valueSat": 20000000,
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.09990000,
      "valueSat": 9990000,
      "n": 0,
      "scriptPubKey": {
        "asm": "a22c8020e029c511da55523565835887e412e5a0c9b920801b007000df45e545f25028248103120c008203000401 OP_CHECKCRYPTOCONDITION",
        "hex": "2ea22c8020e029c511da55523565835887e412e5a0c9b920801b007000df45e545f25028248103120c008203000401cc",
        "reqSigs": 1,
        "type": "cryptocondition",
        "addresses": [
          "R9zHrofhRbub7ER77B7NrVch3A63R39GuC"
        ]
      },
      "spentTxId": "0009bb174ed7ad890d3668c76593566cef18a9aec15cf59343b4a3dce1268100",
      "spentIndex": 0,
      "spentHeight": 176670
    },
    {
      "value": 0.10000000,
      "valueSat": 10000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "02a55f6295cce69932aaedd3e12b4caec263ce1147d5417d7628ebc3e20f970d21 OP_CHECKSIG",
        "hex": "2102a55f6295cce69932aaedd3e12b4caec263ce1147d5417d7628ebc3e20f970d21ac",
        "reqSigs": 1,
        "type": "pubkey",
        "addresses": [
          "RTDSjJMTFaKbvvnkLjm92ZmBCPKSMUJokC"
        ]
      },
      "spentTxId": "a4fa76032480cd31cfce6f2f6a831bfe0cc78de029311c97539bfb3bb5ce24a2",
      "spentIndex": 0,
      "spentHeight": 176681
    },
    {
      "value": 0.00000000,
      "valueSat": 0,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_RETURN e4470b4a8b0b",
        "hex": "6a06e4470b4a8b0b",
        "type": "nulldata"
      }
    }
  ],
  "vjoinsplit": [
  ],
  "valueBalance": 0.00000000,
  "vShieldedSpend": [
  ],
  "vShieldedOutput": [
  ],
  "blockhash": "000000029d36be43a697f09971f1e6329b50b05eb325588f17fe21d665100319",
  "height": 176626,
  "confirmations": 84288,
  "rawconfirmations": 84288,
  "time": 1581867727,
  "blocktime": 1581867727
}

check faucetget txid 0066ddbbb664b96e3762fd069e4258fd0579d7e1dd9b60cc7407460c592d2400 00/00
faucetget validated

Ok, time for a fresh news from the rabbit hole...
The issue with daemon operation on aarch64-linux-gnu is related to memory alignment requirements of target architecture. It happens during CC script parsing, when subroutine tries to free memory used for decode-time stack of nested cc structs. Since that part of code is written in C (not CPP), it's more susceptible to architecture specific limitations and quirks ... especially because structs of pointers are used.

Actually, it's not written by hand yet generated by asn1c compiler. File used as an input is https://github.com/MyHush/hush3/blob/master/src/cryptoconditions/src/asn/CryptoConditions.asn

I've tried to generate new set of C files, with later version of asn1c. Produced files are somewhat different, but offending part of code is the same as current: https://github.com/MyHush/hush3/blob/master/src/cryptoconditions/src/asn/OCTET_STRING.c#L1737-L1745

After making an ugly workaround which skips that part of code for aarch64 architecture, daemon doesn't break when tx contains a CC script. Sync continues, seems ok. This is not final solution because memory leaks ... slowly, but it does.

If CC functionality is soon-to-be obsolete tech in hush network (when mandatory z2z is activated), I wouldn't waste time on making this proper. As far as upstream project is concerned, I believe that migrating cryptoconditions code from C to CPP would be healthy, of course if portability is a part of their roadmap.