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

handling open file descriptor limits with early initialisation #77

Closed
stefantalpalaru opened this issue Sep 15, 2021 · 6 comments
Closed

Comments

@stefantalpalaru
Copy link

When you reach your process' open file descriptor limit, you can no longer produce a backtrace, because libbacktrace tries and fails to open the executable:

libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)
libbacktrace error: failed to read executable information (-1)

What we need is to replace that on-demand file opening with an early one - either by making fileline_initialize() public, so we can call it after backtrace_create_state(), or by including a call to it in the latter function.

@ianlancetaylor
Copy link
Owner

The fix is to call any backtrace function early in your program execution. Once you've done that, libbacktrace shouldn't need to open any more files. You can just discard the results.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Jul 18, 2024
@stefantalpalaru
Copy link
Author

The fix is to call any backtrace function early in your program execution.

My use case was generating stack traces for exceptions in Nim programs: nim-lang/Nim#12922

@ianlancetaylor
Copy link
Owner

OK, but I'm not sure what you are saying. I think that my comment still applies.

@stefantalpalaru
Copy link
Author

I think that my comment still applies.

No, of course not. With exceptions, I collect program counters during stack traversal and use them to generate a stack trace (using libbacktrace) when printing an exception: https://github.com/status-im/nim-libbacktrace/blob/master/libbacktrace.nim

That usually happens at the end of a program, for fatal errors, or in the middle of it, for recoverable ones where we want to log exceptions (and associated stack traces).

@ianlancetaylor
Copy link
Owner

I think that we are somehow failing to communicate.

In the original issue report you said "What we need is to replace that on-demand file opening with an early one - either by making fileline_initialize() public, so we can call it after backtrace_create_state(), or by including a call to it in the latter function."

I am saying that such a function already exists: call backtrace_full and ignore the results.

@stefantalpalaru
Copy link
Author

Got it. Thanks.

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

2 participants