Still stuck on this tritonRoute issue, it's always immediately before

start track assignment

. There is no useful context in the logs, just the console logs before it is killed. I doubt it is OoM as the docker process peaks at about 3.8GB and there is a lot of vacant memory to use. Does anyone have advice on how to figure out the root cause, or potential causes for this? I'll reply in a thread with more context

you can try

gdb

on it see in what part in crashes.

it looks like there's a .params to invoke triton in isolation so I'll see what context I can grab from it

@drr Usually I just set

ulimit -c unlimited

then run gdb on the executable +

core

file post-mortem.

thanks, was wondering why I wasn't see a coredump then realized I'm probably not getting one in this case if it's `SIGKILL`:

start track assignment
Killed

Does

dmesg

show the segfault ?

right, apparently it was OoM, which makes sense given

SIGKILL

, this is in a docker with a host with little apparent memory pressure so when I revisit this, I'll see if there's some docker memory limit I've overlooked

[ 4235.939787] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=3b56e41474d323a7ab9fea7036cb3c92854310f00d71c669cddd181b1b40c1a6,mems_allowed=0,global_oom,task_memcg=/docker/3b56e41474d323a7ab9fea7036cb3c92854310f00d71c669cddd181b1b40c1a6,task=TritonRoute,pid=3181,uid=72580522
[ 4235.943285] Out of memory: Killed process 3181 (TritonRoute) total-vm:2803892kB, anon-rss:1901784kB, file-rss:0kB, shmem-rss:0kB, UID:72580522 pgtables:5336kB oom_score_adj:0
[ 4236.184555] oom_reaper: reaped process 3181 (TritonRoute), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

I can try to clone and run it here.

Thanks. I noticed the "2GB limit" in my docker prefs, that's probably not helping! I'll retry after dialing it up For the caravel stuff I'm doing:

./flow_design -design (abspath to path-to-my-repo/openlane/vdp_lite_user_proj)

It can run off either a design name or a full path to whatever has the

config.tcl

Ah yeah, didn't know you could give an absolute path.

Thanks for trying it, so you can atleast get a GDS out of it I no longer have crashes although I did get a yosys error when writing`*.lvs.powered.v` later on in the flow

Warning: Identifier `\clknet_7_119_0_wb_clk_i' is implicitly declared.

many like this one here, but since it's working for you and I'm using the yosys in the docker, it might be a version issue. The config.tcl was slightly tweaked compared to what you pulled so I'm rerunning with exactly the same one, I'll see what happens

yeah, yosys peaked at 7G

I guess iterating towards DRC clean is going be most of the effort here, just wish it was faster especially for a design that doesn't seem too complex

@drr If you're still getting OoM and you're running under macos, you can click on the docker icon in the menu bar Preferences->Resources and try to add a bit of swap space.

8G seemed to be enough fortunately but the oversize die area was bloating the RAM requirement, I shaved off the excess and it's much faster and less RAM hungry now

yeah, it was rather empty 😅