Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

double free or corruption error during yosys abc9 techmap pass #84

Open
gsomlo opened this issue May 21, 2020 · 4 comments · May be fixed by #89
Open

double free or corruption error during yosys abc9 techmap pass #84

gsomlo opened this issue May 21, 2020 · 4 comments · May be fixed by #89

Comments

@gsomlo
Copy link

gsomlo commented May 21, 2020

See yosys-abc-test.tgz. Reproduce with:

tar xfz yosys-abc-test.tgz
cd yosys-abc-test
abc -s -f ./abc.script

Program fails with:

+ &write -n ./output.aig 
Error: Gia_ManMappingVerify: Internal node -1 does not have mapping.
+ time 
elapse: 53.38 seconds, total: 53.38 seconds
double free or corruption (out)
Aborted (core dumped)

Any idea as to what might be going wrong much appreciated!
@jamesjer
Copy link
Contributor

Valgrind indicates that a pointer into the middle of a malloc()ed block is being passed to free. But even before that, things have gone wrong. Here is the first valgrind complaint:

==62== Invalid read of size 4
==62==    at 0x509CF31: Abc_MaxInt (abc_global.h:272)
==62==    by 0x509CF31: Gia_ManPrintMappingStats (giaIf.c:488)
==62==    by 0x50E5176: Gia_ManPrintStats (giaMan.c:582)
==62==    by 0x4A20333: Abc_CommandAbc9Ps (abc.c:31153)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B02B93: CmdCommandSource (cmd.c:719)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B3EBC8: Abc_RealMain (mainReal.c:330)
==62==    by 0x109165: main (main.c:11)
==62==  Address 0xd63797c is 4 bytes before a block of size 565,412 alloc'd
==62==    at 0x483BAE9: calloc (vg_replace_malloc.c:760)
==62==    by 0x509CDB4: Gia_ManPrintMappingStats (giaIf.c:460)
==62==    by 0x50E5176: Gia_ManPrintStats (giaMan.c:582)
==62==    by 0x4A20333: Abc_CommandAbc9Ps (abc.c:31153)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B02B93: CmdCommandSource (cmd.c:719)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B3EBC8: Abc_RealMain (mainReal.c:330)
==62==    by 0x109165: main (main.c:11)

That suggests that either i or iFan is equal to -1 in the body of the Gia_LutForEachFanin loop at giaIf.c line 488.

The fatal call to free() passes a pointer into the block of memory allocated here:

==62==    at 0x483BAE9: calloc (vg_replace_malloc.c:760)
==62==    by 0x518D2E6: Gia_ManCreateRefs (giaUtil.c:721)
==62==    by 0x517233E: Gia_ManCheckIntegrityWithBoxes (giaSweep.c:426)
==62==    by 0x50E5419: Gia_ManPrintStats (giaMan.c:608)
==62==    by 0x4A20333: Abc_CommandAbc9Ps (abc.c:31153)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B02B93: CmdCommandSource (cmd.c:719)
==62==    by 0x4B0A001: CmdCommandDispatch (cmdUtils.c:153)
==62==    by 0x4B03FD4: Cmd_CommandExecute (cmdApi.c:210)
==62==    by 0x4B3EBC8: Abc_RealMain (mainReal.c:330)
==62==    by 0x109165: main (main.c:11)

Sadly, by that point valgrind has become so confused that it doesn't tell me where that call to free() takes place:

host stacktrace:
==62==    at 0x5804210A: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x58042237: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x580423DB: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x5804CDBA: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x58004B33: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x5800510C: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x5800533E: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x58099ECA: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==62==    by 0x580E5CD4: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)

@jamesjer jamesjer linked a pull request Jun 21, 2020 that will close this issue
Open
This was referenced Aug 15, 2020
Merged
Closed
@jamesjer
Copy link
Contributor

jamesjer commented Aug 9, 2021

Have any abc developers had a chance to look at this? I'm pretty sure my pull request is not the right fix, so it would be great if somebody who understands the code could fix it.

@Ravenslofty
Copy link

@alanminko could you look at this please?

@rowanG077
Copy link

Still hitting this as of most recent yosys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Skip the body of Gia_LutForEachFanin if iFan is negative. jamesjer/abc
4 participants
@gsomlo @Ravenslofty @jamesjer @rowanG077