> The main quic connection is created in ngx_quic_new_connection(), which
> calls ngx_quic_open_sockets() and it sets c->udp for the first time.

> When packet arrives, c->udp is updated by ngx_lookup_udp_connection().

> The main connection does not have c->quic set; this is used in stream
> connections. To access main connection from quic stream, c->quic->parent
> may be used.

ngx_event_recvmsg->(ls->handler) ngx_http_init_connection->ngx_http_v3_init:
if (c->quic == NULL) {
h3scf->quic.timeout = clcf->keepalive_timeout;
ngx_quic_run(c, &h3scf->quic);
return;
}

And, why check c->quic == NULL, as it is never set
c->read->handler = ngx_quic_input_handler; in ngx_quic_run.
ngx_quic_close_connection maybe called in ngx_quic_input_handler, and it finally call ngx_ssl_shutdown(c), which cannot return immediately as c->quic is never set.
And maybe ngx_handle_read_event add c->read to events group finally

Gao,Yan(ACG VCP)

发件人: "Gao,Yan(媒体云)" <gaoyan09@baidu.com>
日期: 2022年1月26日 星期三 下午6:00
收件人: "nginx-devel@nginx.org" <nginx-devel@nginx.org>
主题: Re: [quic] ngx_quic_input_handler Segmentation fault because c->udp->dgram is null

> the case you are describing is not what see in backtrace. And in
> described case connection is main quic connection which has process
> c->quic pointer set.

I only find sc->quic = qs; in ngx_quic_create_stream，and this is stream connection, not the main quic connection.
How the main quic connection c->quic set?

And the local code at this position:
changeset: 8813:c37ea624c307
branch: quic
tag: tip
user: Roman Arutyunyan <arut@nginx.com>
date: Fri Jan 21 11:20:18 2022 +0300
summary: QUIC: changed debug message.

Gao,Yan(ACG VCP)

_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-leave@nginx.org