Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Segmentation fault (core dumped) #527

Closed
ansigroup opened this issue Jun 15, 2019 · 5 comments
Closed

Segmentation fault (core dumped) #527

ansigroup opened this issue Jun 15, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@ansigroup
Copy link

ansigroup commented Jun 15, 2019

Hello,

we found an issue (cdt 1.5.0-1.6.1) on using construction which include array of self objects, like std::vector<testtab> :

TABLE testtab {
  uint64_t    id;
  std::vector<testtab> container; 

  auto primary_key() const {  return id; }
};

This construction is used in simpleassets.io (NFT standart) for attaching NFTs and FTs into others NFTs (https://github.com/CryptoLions/SimpleAssets/blob/master/include/SimpleAssets.hpp#L529)

Using CDT 1.5.0 - wasm was created but abi was failed. For deploying wasused manually modified abi file (https://github.com/CryptoLions/SimpleAssets/blob/master/SimpleAssets.abi#L539) and result was OK (img below).

image

With cdt 1.6.1. building is failed totaly and no wasm or abi is created.

Test project with construction:
test.tar.gz

Thanks,
Best Regards,
Bohdan

@jeffreyssmith2nd
Copy link
Contributor

Confirmed on 1.6.2 as well.

@jeffreyssmith2nd jeffreyssmith2nd added the bug Something isn't working label Jul 17, 2019
@jeffreyssmith2nd
Copy link
Contributor

Actually, I must have tested with 1.6.1. With 1.6.2 (built from source on the v1.6.2 tag), the compilation succeeds but the ABI generation fails. Can you test again with 1.6.2 and let me know what results you get?

@ansigroup
Copy link
Author

Actually, I must have tested with 1.6.1. With 1.6.2 (built from source on the v1.6.2 tag), the compilation succeeds but the ABI generation fails. Can you test again with 1.6.2 and let me know what results you get?

tested on 1.6.2 failed both abi and wasm.

@jeffreyssmith2nd
Copy link
Contributor

Tested again with the brew package for 1.6.2 and am indeed seeing this. Not sure why it seemed like I wasn't previously.

conr2d added a commit to haderech/eoscc that referenced this issue Aug 25, 2019
`add_type` calls itself recursively to add all types it refers to.
If user-defined types refer to each other or themselves, it causes
stack overflow by cycle.

EOSIO/eosio.cdt#527
conr2d added a commit to conr2d/eosio.cdt that referenced this issue Aug 25, 2019
`add_type` calls itself recursively to add all types it refers to.
If user-defined types refer to each other or themselves, it causes
stack overflow by cycle.

EOSIO#527
conr2d added a commit to haderech/eoscc that referenced this issue Aug 25, 2019
`add_type` calls itself recursively to add all types it refers to.
If user-defined types refer to each other or themselves, it causes
stack overflow by cycle.

EOSIO/eosio.cdt#527
@ansigroup
Copy link
Author

Issue fixed. Just confirmed. Thank you very much.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants