Closed mojomojomojo closed 2 years ago
Feel free to submit a pull request which fixes this.
I realize that this is a niche error, but why assume that the entries are in the correct order instead of just reading them in the order they need to be read?
The simplest answer is because Very Sleepy reasonably expects that Very Sleepy is the only application which creates .sleepy
files. The fact that they're a ZIP archive with human-readable contents is an implementation detail.
I totally understand why it's not a real issue. It was just a bit hacking-unfriendly. Most zip tools don't provide a way to reorder the items in an archive.
I was attempting to hack a .sleepy file to "enhance" the cached symbols, and the resultant zip archive kept causing errors when I try to load it in Very Sleepy.
When I try to load a file that Very Sleepy created (that I didn't touch—the original file, in fact), I noticed that it loads the items in a different order. It looks like the item order is important, though it doesn't do anything to guarantee that it reads the items in any particular order.
database::loadFromPath
In my case, it was crashing in database::loadCallstacks when it was attempting to index the
addrinfo
vector which had not yet been populated. It looks like it gets populated indatabase::loadSymbols
.I realize that this is a niche error, but why assume that the entries are in the correct order instead of just reading them in the order they need to be read?