Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Too long paths will result in an assert error during startup #3807

Closed
DorpsGek opened this issue May 2, 2010 · 7 comments
Closed

Too long paths will result in an assert error during startup #3807

DorpsGek opened this issue May 2, 2010 · 7 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented May 2, 2010

Progman opened the ticket and wrote:

r19728

If you have very long paths inside ~/.openttd/ OpenTTD can crash if during startup a search path is generated which does not end in a /. This results in the following assertion

Assertion failed at line 102 of /home/progman/openttd/trunk/src/os/unix/unix.cpp: path[strlen(path) - 1] == PATHSEPCHAR

This can be reproduced by creating two symlinks in content_download/ with the names "recursion" and "recursion2" which points to "." (content_download). During startup the content_download/ directory is searched recursively for all files. With these symlinks it creates a path which is greater than the "path" array and so the path is truncated. This also means the trailing slash is cut off, so the assertion is thrown. In the attached strace log you see how the paths are generated and how a directory path is generated which does not end in a slash.

The question of course is why would someone create such symlinks in a directory which is recursively loaded ;). Adding such of symlinks increase the load time during startup, specially if the names are very short (like "a"->. and "b"->.). These would result in an endless recursion lookup of a binary tree (only terminated by ELOOP (Too many levels of symbolic links)). Maybe a realpath() call can help here.

Attachments

Reported version: trunk
Operating system: Linux

This issue was imported from FlySpray: https://bugs.openttd.org/task/3807
@DorpsGek
Copy link
Member Author

DorpsGek commented May 8, 2010

Rubidium wrote:

Does the attached patch fix the problem?

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8008

@DorpsGek
Copy link
Member Author

DorpsGek commented May 8, 2010

Progman wrote:

It does not. Even if the path does not end with a slash as it is cut off from the path variable maximum size the path itself is still valid. As you see in the strace output it runs the lstat() on "/home/progman...../recursion", which is a valid existing path, it just doesn't end with a slash.

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8009

@DorpsGek
Copy link
Member Author

DorpsGek commented May 9, 2010

Rubidium wrote:

Okay, so the ELOOP error is not (yet) triggered... too bad.
Also realpath is basically an unusable function, at least without deliberately crashing older libcs and/or not working properly on non-POSIX 2008 but POSIX 2001 platforms.

In other words, this is going to require something more drastical.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8010

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Does the attached patch fix the problem?

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8015

@DorpsGek
Copy link
Member Author

Progman wrote:

Yes, this works now. I don't get an assert anymore. Its funny to see via strace how the new size limit (4096 on my system) is used to build any possible path of combination of /recursion/ and /recursion2/ ;) (about 2^350)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8016

@DorpsGek
Copy link
Member Author

Rubidium wrote:

I doubt every path combination is tested if it is 2 to the power of 350 combinations. Just assume that every check takes exactly 1 CPU cycle (it'll take many many more), your CPU can do 4 billion ticks per second (2^32) (4 GHz, single core), then it would take 2^318 seconds to complete. One hour is 86400 seconds, so 2^17 if rounded up, which means doing it completely would have taken at least 2^300 times longer.

A year has about 2^25 seconds, the universe is about 15 billion years old so 2^34 years. Which means it would take at least 2^240 times as long as the (current) universe has lasted, unless we assume that the universe is God's creation and is considerably less than 15 billion years old, but that still means at least 2^260 times as long.

As such I highly doubt it would have checked even near 2^350 combinations.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807#comment8017

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

Around r19780.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3807

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek