> 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(媒体云)" <gaoya...@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 <a...@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-le...@nginx.org
