call getLocalAddress should after server initializing.

[iamjustadd]

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
[email protected] where the issue will be triaged appropriately.

Title: One line description
call getLocalAddress should after server initializing.

Description:

What issue is being seen? Describe what should be happening instead of
the bug, for example: Envoy should not crash, the expected value isn't
returned, etc.
In source/exe/main_common.cc line 75:
auto local_address = Network::Utility::getLocalAddress(options_.localAddressIpVersion());

There is a RELEASE_ASSERTION in getLocalAddress. This called before server logging initializing.
So there will get only a crash coredump without any log for this crash.

Actually it is more proper to pass a nullptr as value of local_address into Server::InstanceImpl constructor.

So that in constructor we can call getLocalAddress after initialize the file_logger_ like:

in main_common.cc line 88:
server_ = std::make_uniqueServer::InstanceImpl(
*init_manager_, options_, time_system, nullptr, listener_hooks, *restarter_,
*stats_store_, access_log_lock, component_factory, std::move(random_generator), *tls_,
platform_impl_->threadFactory(), platform_impl_->fileSystem(), std::move(process_context));

Then in server.cc line 111:

• if (!local_address) {

•  local_address = Network::Utility::getLocalAddress(options.localAddressIpVersion());
  

• }

Repro steps:

Include sample requests, environment, etc. All data and inputs
required to reproduce the bug.

Note: The Envoy_collect tool
gathers a tarball with debug logs, config and the following admin
endpoints: /stats, /clusters and /server_info. Please note if there are
privacy concerns, sanitize the data prior to sharing the tarball/pasting.

Admin and Stats Output:

Include the admin output for the following endpoints: /stats,
/clusters, /routes, /server_info. For more information, refer to the
admin endpoint documentation.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Config:

Include the config used to configure Envoy.

Logs:

Include the access logs and the Envoy logs.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Call Stack:

If the Envoy binary is crashing, a call stack is required.
Please refer to the Bazel Stack trace documentation.

[iamjustadd]

Sorry, Im not realizing that these comments will be visible in this page..

[wbpcode]

Hi, could you provide you envoy version and how to reproduce this problem?

[iamjustadd]

We are developing based on v1.24.6. This is an intermittent problem. We don't know exactly how to reproduce this , sometimes when the network not initializing well, the coredump would be generated.

#0 raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00000000017976cb in Envoy::SignalAction::sigHandler(int, siginfo_t*, void*) () at source/common/signal/signal_action.cc:53
#2
#3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#4 0x00000056a5117df4 in __GI_abort () at abort.c:79
#5 0x0000000001769a5d in Envoy::Network::Utility::getLocalAddress(Envoy::Network::Address::IpVersion) () at source/common/network/utility.cc:204
#6 0x0000000000a77d55 in Envoy::MainCommonBase::MainCommonBase(Envoy::Server::Options const&, Envoy::Event::TimeSystem&, Envoy::ListenerHooks&, Envoy::Server::ComponentFactory&, std::unique_ptr<Envoy::Server::Platform, std::default_deleteEnvoy::Server::Platform >, std::unique_ptr<Envoy::Random::RandomGenerator, std::default_deleteEnvoy::Random::RandomGenerator >&&, std::unique_ptr<Envoy::ProcessContext, std::default_deleteEnvoy::ProcessContext >) () at ./source/server/options_impl.h:124
#7 0x0000000000a7887a in Envoy::MainCommon::MainCommon(int, char const* const*) ()

Failed at RELEASE_ASSERT(!rc.return_value_, fmt::format("getifaddrs error: {}", rc.errno_));

Here, rc.errno_ is: details = "getifaddrs error: 22"

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.