<@U016H5X1K62>, <@U016Q6CGUCB>: The way to run ma...
# magic
t
@User, @User: The way to run magic under a debugger to get a stack trace on segfault (assuming you have the full command line as shown above) is to run (assuming a standard install location for magic in the /usr/local/ path) is:
gdb /usr/local/lib/magic/tcl/magicdnull
followed by (on the gdb command line)
run -- -noconsole -dnull -rcfile /openLANE_flow/designs/spm/runs/06-08_21-36/tmp/magic_antenna.magicrc /openLANE_flow/designs/spm/runs/06-08_21-36/tmp//magic_antenna.tcl
. When it crashes, it returns to the gdb prompt, where you can run
bt
to see the stack.
y
I did try investigating the problem with a debugger but docker complicates it somewhat. I need to install gdb inside the docker image which is totally doable but I haven't tried it yet. I might just try installing openlane natively to make debugging easier
t
@yrrapt If you can access the docket system room, you can also analyze the core file using a gdb on the host and just point to the binary inside the docker and to the docker sysroot (for library loading)
y
@tnt OK that's good to know. I was wondering if something like that was possible. Will give a spin this evening and see if I can get it working. Thanks for the tip
@Tim Edwardsmanaged to get some more info:
Copy code
#0  memcpy () at ../sysdeps/x86_64/memcpy.S:513
#1  0x00007f70b8a6e2a0 in dbcConnectFunc (tile=0x7f70bc914518, cx=0x7ffdc7e478e0) at DBconnect.c:958
#2  0x00007f70b8a904ac in DBSrPaintArea (hintTile=0x0, plane=0x1f55960, rect=0x7ffdc7e479a0, mask=0x7f70b9729440, func=0x7f70b8a6dd05 <dbcConnectFunc>, arg=140727957092576) at DBtiles.c:439
#3  0x00007f70b8a686e3 in dbCellPlaneSrFunc (scx=0x7ffdc7e47990, fp=0x7ffdc7ebcf50) at DBcellsrch.c:264
#4  0x00007f70b8a6a050 in dbCellSrFunc (use=0x20c1be0, cxp=0x7ffdc7ebce30) at DBcellsrch.c:1165
#5  0x00007f70b8a68404 in DBSrCellPlaneArea (plane=0xded2d0, rect=0x7ffdc7ebd560, func=0x7f70b8a69c37 <dbCellSrFunc>, arg=140727957573168) at DBcellsrch.c:91
#6  0x00007f70b8a69c1d in DBCellSrArea (scx=0x7ffdc7ebd550, func=0x7f70b8a68527 <dbCellPlaneSrFunc>, cdarg=140727957573456) at DBcellsrch.c:1117
#7  0x00007f70b8a68723 in dbCellPlaneSrFunc (scx=0x7ffdc7ebd550, fp=0x7ffdc7ebcf50) at DBcellsrch.c:275
#8  0x00007f70b8a684b4 in DBTreeSrTiles (scx=0x7ffdc7ebd550, mask=0x7f70b9729440, xMask=0, func=0x7f70b8a6dd05 <dbcConnectFunc>, cdarg=140727957574656) at DBcellsrch.c:174
#9  0x00007f70b8a6e4ea in DBTreeCopyConnect (scx=0x7ffdc7ebd550, mask=0x7f70b97292a0, xMask=0, connect=0x7f70b97290a0, area=0x7f70b8e70960, doLabels=0 '\000', destUse=0x1b092a0) at DBconnect.c:1070
#10 0x00007f70b8bce7c7 in antennacheckVisit (dev=0xc341e0, hc=0x7ffdc7ebd720, scale=1, trans=0x7ffdc7ebd670, editUse=0x1e3b130) at EFantenna.c:507
#11 0x00007f70b8bccfcc in efVisitDevs (hc=0x7ffdc7ebd720, ca=0x7ffdc7ebd830) at EFvisit.c:324
#12 0x00007f70b8bc92e4 in efHierSrUses (hc=0x7f70b990bee0, func=0x7f70b8bcceae <efVisitDevs>, cdata=140727957575728) at EFhier.c:92
#13 0x00007f70b8bccf05 in efVisitDevs (hc=0x7f70b990bee0, ca=0x7ffdc7ebd830) at EFvisit.c:309
#14 0x00007f70b8bcceac in EFVisitDevs (devProc=0x7f70b8bcdf05 <antennacheckVisit>, cdata=31699248) at EFvisit.c:280
#15 0x00007f70b8bcde26 in CmdAntennaCheck (w=0xd6a890, cmd=0xd96b00) at EFantenna.c:238
#16 0x00007f70b8b17eba in WindExecute (w=0xd6a890, rc=9271184, cmd=0xd96b00) at windMain.c:414
#17 0x00007f70b8a9c2cb in DBWcommands (w=0xd6a890, cmd=0xd96b00) at DBWprocs.c:598
#18 0x00007f70b8b149e1 in WindSendCommand (w=0xd6a890, cmd=0xd96b00, quiet=1 '\001') at windSend.c:263
#19 0x00007f70b8b0cd19 in TxTclDispatch (clientData=0x0, argc=1, argv=0x84bc20, quiet=1 '\001') at txCommands.c:1180
#20 0x00007f70b8c159db in _tcl_dispatch (clientData=0x0, interp=0x84a850, argc=1, argv=0x84bc20) at tclmagic.c:400
#21 0x00007f70bc16e9ff in TclInvokeStringCommand () from /usr/lib64/libtcl8.5.so
#22 0x00007f70bc16fa63 in ?? () from /usr/lib64/libtcl8.5.so
#23 0x00007f70bc17052f in ?? () from /usr/lib64/libtcl8.5.so
#24 0x00007f70bc1dce61 in Tcl_FSEvalFileEx () from /usr/lib64/libtcl8.5.so
#25 0x00007f70bc1dcf9f in Tcl_EvalFile () from /usr/lib64/libtcl8.5.so
#26 0x00007f70b8b5bdbf in mainInitFinal () at main.c:1164
#27 0x00007f70b8c16458 in _magic_startup (clientData=0x0, interp=0x84a850, argc=1, argv=0x84b7f0) at tclmagic.c:725
#28 0x00007f70bc16e9ff in TclInvokeStringCommand () from /usr/lib64/libtcl8.5.so
#29 0x00007f70bc16fa63 in ?? () from /usr/lib64/libtcl8.5.so
#30 0x00007f70bc17052f in ?? () from /usr/lib64/libtcl8.5.so
#31 0x00007f70bc1dce61 in Tcl_FSEvalFileEx () from /usr/lib64/libtcl8.5.so
#32 0x00007f70bc1dcf9f in Tcl_EvalFile () from /usr/lib64/libtcl8.5.so
#33 0x00007f70bc1e2aa0 in Tcl_SourceRCFile () from /usr/lib64/libtcl8.5.so
#34 0x00007f70bc1e30f0 in Tcl_Main () from /usr/lib64/libtcl8.5.so
#35 0x000000000040080b in main (argc=7, argv=0x7ffdc7ebea18) at magicdnull.c:49
t
@yrrapt: In my magic code, assuming the version is close to the same, the line it crashed on was the middle line of the lines below:
Copy code
newlist = (conSrArea *)mallocMagic((size_t)(csa2->csa2_size) * sizeof(conSrArea));
        memcpy((void *)newlist, (void *)csa2->csa2_list, (size_t)lastsize * sizeof(conSrArea));
        freeMagic((char *)csa2->csa2_list);
My immediate question is what are the values "newlist" and "lastsize". My guess is that the design was big enough that "newsize" hit the limit of an integer to hold the value and that it needs to be changed to a 64 bit "long" integer. What is the size (WxL dimension) of the design you were running this on?
y
@Tim Edwards It's only the recommended 'spm' example. In KLayout it's ~160x160 um. You'll have to excuse my crusty debugging skills, how can I read those values? I've got as far as
print 'DBconnect.c'::dbcConnectFunc:
which prints the function information but if I try
print 'DBconnect.c'::dbcConnectFunc::newlist
I just get
No symbol "newlist" in specified context.
I was overcomplicating it. The value of newlist is
$4 = (conSrArea *) 0x21d8600
and lastsize is
67108864
67108864 is a round 26 bits so seems fine.
sizeof(conSrArea)
is coming out at 32 so will only add another 5 bits
t
@yrrapt : 67108864 * 32 = -2147483648
Since (size_t) should be the size of a pointer, this seems impossible to overflow (size_t) unless magic has somehow been compiled to a 32 bit target instead of a 64 bit target. What does gdb tell you if you do "print sizeof(size_t)"?
y
@Tim Edwards that gives me 8
t
@yrrapt: Then the only thing I can think of is that an obnoxiously obtuse compiler was unable to interpret "(size_t)lastsize * sizeof(conSrArea)". Needs more parentheses??
@yrrapt: Or does the system it's compiled on have (int) instead of (size_t) for the last argument to memcpy()?
@yrrapt: Uh. . . I think magic has been done in by Tcl. Tcl_Alloc() seems to improperly use (unsigned int) instead of (size_t) for its memory allocation routine. Hard to believe. Is that really true? Yet I recall running into that issue before.
@yrrapt: Probably the solution is NOT to depend on Tcl's allocation routines but in the magic source code at utils/malloc.c line 77 change
Copy code
#define MallocRoutine(a) Tcl_Alloc(a)
#define FreeRoutine(a) Tcl_Free(a)
to:
Copy code
#define MallocRoutine(a) malloc(a)
#define FreeRoutine(a) free(a)
I think this will work without problems. I do not believe there is any mixing of Tcl and non-Tcl memory allocation and freeing in the code.
I have pushed this change to the git repo on opencircuitdesign.com but it needs to be vetted, and the openlane docker build would need to be updated.