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

cloud example coredump when specify options max_log_file_size #281

Open
wangshao1 opened this issue Aug 23, 2023 · 0 comments
Open

cloud example coredump when specify options max_log_file_size #281

wangshao1 opened this issue Aug 23, 2023 · 0 comments

Comments

@wangshao1
Copy link

Note: Please use Issues only for bug reports. For questions, discussions, feature requests, etc. post to dev group: https://groups.google.com/forum/#!forum/rocksdb or https://www.facebook.com/groups/rocksdb.dev

Expected behavior

Actual behavior

when specify options.max_log_file_size to a none zero value, process coredumps because of a fail assert about cloud_manifest.
Here is the stack
截屏2023-08-23 21 38 26
When rocksdb open and options.info_log is nullptr, rocksdb will create a autorolllogger,autorolllogger's construct function will find exist old LOG files by calling env->filesystem()->GetChildren(). In rocksdb-cloud, env->filesystem is cloudFileSystem which will do RemapFilename for some files, but cloud_manifest has not been loaded yet.
In my opinion, the LOGs will not been uploaded to cloud and not need to be synchonized either. So maybe we can pass filesystem::Default() when constructing autorolllogger? Or add extra member varable in env to represent base_fs_?

Steps to reproduce the behavior

specify options.max_log_file_size or options.log_file_time_to_roll to a none zero value.
run example in cloud sub dir twice(To make the local_dir is not empty).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant