Dockerd crashes on start even after reinstall

I was recently working with creating an image based off a Selenium image, and was running a lot of docker compose up -d --build to rebuild and test my Dockerfile. One time the build got an error message, and it crashed the demon and I’ve failed to get it back up and running even with reinstalling. It generated a lot of stack trace, so I saved it to a gist instead of copying it all here: dockerd error · GitHub.

I don’t have anything irreplaceable, so I was poking around a bit in /var/lib/docker trying to delete stuff related to the image I was working on and my next step will just be to delete that entire directory and perform another fresh reinstall, but it would be nice to find a solution if anybody has any insight into what this issue could be.

jeremy@trillian ~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Pop
Description:	Pop!_OS 22.04 LTS
Release:	22.04
Codename:	jammy

jeremy@trillian ~ $ uname -a
Linux trillian 6.8.0-76060800daily20240311-generic #202403110203~1715181801~22.04~aba43ee SMP PREEMPT_DYNAMIC Wed M x86_64 x86_64 x86_64 GNU/Linux

jeremy@trillian ~ $ docker version
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Client: Docker Engine - Community
 Cloud integration: v1.0.29
 Version:           26.1.3
 API version:       1.45
 Go version:        go1.21.10
 Git commit:        b72abbb
 Built:             Thu May 16 08:33:29 2024
 OS/Arch:           linux/amd64
 Context:           default

Never ever edit anything manually in the Docker data root unless you are really familiar with its filesystem. I don’t recognize anything it the stack trace, so if you changed anything in the Docker data root and you have nothing you would miss by uninstalling Docker, deleting the docker data root entirely and reinstalling Docker, I’m afraid that’s the way. If it were really important, you could try to fix the filesystem, but that woul be hard enough for me (if possible) as well and I played a lot with the Docker filesystem.

If the logs are from the time before changing the content of the Docker data root, I still don’t know what the stack trace means. If it happened during a build, maybe there were a memory issue or kernel panic and somehow it broke Docker filesystem alone, but I have never seen similar issues.