"Assertion '0' failed in pkg/noun/manage.c:1801" on boot

[AshleyYakeley]

Running in Docker, using image tloncorp/urbit:latest, ID 62fa12a794b1.

~
disk: loaded epoch 0i107273048
urbit 3.0
boot: home is /urbit/litsel-tabfer
live: mapped: GB/2.137.260.032
live: loaded: KB/16.384
loom: mapped 2048MB
boot: protected loom
boot: installed 967 jets
---------------- playback starting ----------------
loom: ward bogus (>130805 130869 130870<)
Assertion '0' failed in pkg/noun/manage.c:1801

bail: oops
bailing out

[joemfb]

This error is consistent when you try to restart?

[AshleyYakeley]

Yes. I stopped the container, deleted the docker log, and started it again.

Running with no STDIN
~
disk: loaded epoch 0i107273048
urbit 3.0
boot: home is /urbit/litsel-tabfer
live: mapped: GB/2.137.260.032
live: loaded: KB/16.384
loom: mapped 2048MB
boot: protected loom
boot: installed 967 jets
---------------- playback starting ----------------
loom: ward bogus (>130805 130869 130870<)
Assertion '0' failed in pkg/noun/manage.c:1801

bail: oops
bailing out
play: events 111561337-111561474Running with no STDIN
~

[joemfb]

@AshleyYakeley sorry for the delay, I missed your reply.

Your loom is almost full -- that "ward bogus" printf shows that you have 65 16KB pages of free space left. The assertion is catching a write out-of-bounds: we hit the guard page (index 130869), but it's properly within the bounds of the free space. I'd guess that we overflowed our "road stack".

The easiest way to get past this is to do one or more of the following: run with a larger loom (--loom 32 or 33), defragment the persistent state with $pier/.run pack, or deduplicate the persistent state with $pier/.run meld.

Before you do that, if you're willing, it'd be great to extract a stacktrace from this pier and see what exactly is causing the fault. You can run it in gdb:

gdb --args $pier/.run
b events.c:257
handle SIGSEGV nostop noprint
r

And then run bt when it breaks.

[AshleyYakeley]

I don't seem to have a .run file in my stuff? I have a .urb directory but it's not in that.

I'm running urbit in Docker if that makes a difference.

[joemfb]

My bad, you did say you're running in the container. I haven't used it myself -- @mopfel-winrux can you tell us how to debug in this case?

[mopfel-winrux]

You can't do it in the docker file, you will need to download an urbit runtime and use the docker volume

[AshleyYakeley]

Is there an option to run with a larger loom in a Docker container?

[mopfel-winrux]

You should be able to pass it the --loom 32 command to the /bin/start-urbit script when you start it up

[AshleyYakeley]

OK, --loom=32 worked, and I updated the kernel version to b4l49.

Is there anything else I need to do at this point?

[joemfb]

Glad you're up and running. I've opened urbit/vere#641 to track the underlying issue.

[AshleyYakeley]

All good. Thanks for the help, sorry I couldn't help debug the issue.