Я недавно сталкивался с этим, но я также видел несколько примеров в Интернете, где кажется, что люди сообщают о segfault с помощью функции ngx_log_error_core.Но, похоже, все исправление связано с «исправлением вызывающего кода ниже ngx_log_error_core в трассировке стека, чтобы он не попадал в путь регистрации ошибок»:
https://github.com/kvspb/nginx-auth-ldap/issues/56, исправлено https://github.com/kvspb/nginx-auth-ldap/pull/65
https://forum.nginx.org/read.php?2,66090,128251#msg-128251 объясняется https://trac.nginx.org/nginx/ticket/300#no1 и фиксируется https://trac.nginx.org/nginx/ticket/91
https://trac.nginx.org/nginx/ticket/489 кто-то говорит, что понятно проблема стороннего кода (строки подверхний след ngx_log_error_core)
https://github.com/apache/incubator-pagespeed-ngx/issues/79, исправлено в https://github.com/apache/incubator-pagespeed-ngx/pull/80
https://github.com/apache/incubator-pagespeed-ngx/issues/1097
Я только что столкнулся с подобным случаем, но неУ него нет способа надежно воспроизвести поведение, за исключением исправления логики, которая в первую очередь приводит к ошибке регистрации.
Почему это когда-либо происходит?Почему повторное обращение к ngx_log_error_core может привести к segfault?