From scan-admin at coverity.com Mon Sep 2 08:51:50 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 02 Sep 2024 08:51:50 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66d57ca5d3d7e_1951f62bc46f755990549c@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3D7J5x_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR17TaIOsfhFONMeVWWUswzZYRjiha2OavF1JprCOW-2Fp20-2B0YFP4Z1CvVpx5BpFu76QohHVEE0TeSV5APejRK-2FhIIjW1BLiJCM-2FThDRlcXgqskUdMyHAAcJ70qiydY0EmYO8a0A5SVyX7TO3-2B-2FqTKzKPzWBilKC-2F8DbXqM14hp3BjI8-2FyS-2FFp8uG8fdrTc8LAjY-3D Build ID: 638313 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Mon Sep 9 08:27:06 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 09 Sep 2024 08:27:06 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66deb159ec4f1_2041a72bc46f75599054971@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DQ-68_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR1JCW4bcFwiM-2FpX-2BQUyu1XSe8A4oPLCgm7t8pVUXH0uX6DwLeZBGcZZMfi-2FOOt4LSbL8TN9LWXuw7PYBHMwTl1-2BkJV7AUSBYpccsVkHXRnhfEN7X5KJ0E2puKvnxUUohSx-2F-2F8my1THoyD19FtkstqubVHe9Coi3bmEHlSqrZ61sqAbRB2uxNEwSriR-2FBwZAiGY-3D Build ID: 639869 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Thu Sep 12 16:22:47 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Thu, 12 Sep 2024 16:22:47 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66e31556adf92_23aae42bc46f755990549bc@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DrTCy_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR0GpS7Y2nLHFOaM08lrdgFTqT97TaV3yf0Uzk9ne1tArTrVmKNU0LLKfBFO0stWvtymho51F4xmZlyY6OKGWIvkSXaJUu0rzvEDlWYqZaDygAzefg0E3tzPK5LEmx8AUl607qEUnleKzdLvrG1Azg2H1jXsash3c1TRrex-2BEPLgI0Zh9bj5yMbYEdotBw99Ckc-3D Build ID: 640632 Analysis Summary: New defects found: 0 Defects eliminated: 5 From scan-admin at coverity.com Mon Sep 16 08:11:53 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 16 Sep 2024 08:11:53 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66e7e848e51d7_2750042bc46f755990549ba@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DofnG_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR3U9pnuYPh1Wd1NY0K6cGjZu10BJfYJtsjQDxdee18IkPQE90kjrf-2BKp4LCM26p5NJydi-2BOZEBGOvZ-2FZvtCnvXsPlUuAZR9wBvf-2BlYNY2eO-2F5w2WO4-2FE3LY38D-2BWKoOX-2FxeINX-2BkOAHVoyP7LUeQMA8ZaFDWOqyOhouLCCw3vj-2BdiapUj-2BcxFjqAU7LUxb18E4-3D Build ID: 641430 Analysis Summary: New defects found: 0 Defects eliminated: 0 From carlos.abalde at gmail.com Tue Sep 17 09:54:01 2024 From: carlos.abalde at gmail.com (Carlos Abalde) Date: Tue, 17 Sep 2024 11:54:01 +0200 Subject: Error handling in the constructor of a VMOD object Message-ID: <7db2fd38-507f-4b26-b86a-4e4a4e8a00cf@gmail.com> Hi all, I'm looking for advise / best-practices related to VMODs, objects and their __init() constructors. Let's assume a foo VMOD and a VCL like this one: import foo; sub vcl_init { ? new myfoo = foo.instance(...); ? ... } What's your suggestion to handle errors in the constructor? So far my approach is returning a NULL pointer if for some reason the instance cannot be created, which IMO is good enough because that way execution of 'vcl_init' will continue (meh...), but in the end it will fail (with a slightly obscure error), and then the VCL won't be loaded. However, in such a scenario ans using that strategy, a VCL like this one would trigger a panic: sub vcl_init { ? new myfoo = foo.instance(...); ? myfoo.whatever(...); ? ... } Transforming all VMOD methods in no-ops when the received pointer is NULL could be an option, but it looks ugly. I guess another option would be to add a '.isnull()' method to the object and then use it in 'vcl_init': sub vcl_init { ? new myfoo = foo.instance(...); ? if (myfoo.isnull()) { ??? return (fail); ? } ? myfoo.whatever(...); ? ... } My doubt is if I'm missing something and a better approach already exists for error handling during 'vcl_init'. Any suggestion? Thanks, -- Carlos Abalde -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at uplex.de Tue Sep 17 10:55:52 2024 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 17 Sep 2024 12:55:52 +0200 Subject: Error handling in the constructor of a VMOD object In-Reply-To: <7db2fd38-507f-4b26-b86a-4e4a4e8a00cf@gmail.com> References: <7db2fd38-507f-4b26-b86a-4e4a4e8a00cf@gmail.com> Message-ID: <0265a6f5-6fd2-41a0-b51b-e2e4ee20a5b1@uplex.de> On 9/17/24 11:54, Carlos Abalde wrote: > > I'm looking for advise / best-practices related to VMODs, objects and > their __init() constructors. > What's your suggestion to handle errors in the constructor? if (failure) { VRT_fail(ctx, "printf-like format %string", args, ...); return; } When VRT_fail() is invoked during the function implementing the constructor, the execution of vcl_init is aborted, and the VCL load fails. The CLI prints an error message that the VCL "Failed initialization", and then the formatted message from VRT_fail() in the next line. That's where you can describe the error. It's very much like a VCL compile failure in that the VCL doesn't load. The difference being that the CLI returns status 300 for an initialization failure, but 106 for a syntax error. You might want the return right after VRT_fail(), unless you have to do some resource cleanup first. At any rate, you can discontinue the C function as soon as possible. HTH, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From carlos.abalde at gmail.com Tue Sep 17 11:33:23 2024 From: carlos.abalde at gmail.com (Carlos Abalde) Date: Tue, 17 Sep 2024 13:33:23 +0200 Subject: Error handling in the constructor of a VMOD object In-Reply-To: <0265a6f5-6fd2-41a0-b51b-e2e4ee20a5b1@uplex.de> References: <7db2fd38-507f-4b26-b86a-4e4a4e8a00cf@gmail.com> <0265a6f5-6fd2-41a0-b51b-e2e4ee20a5b1@uplex.de> Message-ID: <08b6dd37-ef76-41c7-8b9e-a59f73d06245@gmail.com> On 9/17/24 12:55, Geoff Simmons wrote: > On 9/17/24 11:54, Carlos Abalde wrote: >> >> I'm looking for advise / best-practices related to VMODs, objects and >> their __init() constructors. >> What's your suggestion to handle errors in the constructor? > if (failure) { > ????VRT_fail(ctx, "printf-like format %string", args, ...); > ????return; > } > > When VRT_fail() is invoked during the function implementing the > constructor, the execution of vcl_init is aborted, and the VCL load > fails. Oh! I've being using 'VRT_fail()' to handle as 503 responses unrecoverable VMOD error conditions during normal operation, but I didn't know / considered it could be using also for initializations. Thanks for the tip! Best, -- Carlos Abalde -------------- next part -------------- An HTML attachment was scrubbed... URL: From scan-admin at coverity.com Mon Sep 23 09:02:31 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 23 Sep 2024 09:02:31 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66f12ea64b045_2e388e2ac9b6e7b9a4493f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DzMIV_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR2YUj3R3pEls0vp88qfiXOra8fI266-2BH2zE77xGMZNgLIBpyHk2Ami7tTjtejusBY0ti1-2FEkCJ-2BlF3jO7goc42uOHfgOS3iv-2Fn9-2FCREpJPCRtUdd6KWAJpz3aJgE2iDd1Abp6JqwNIAntdxC-2Fe2XUUMSmAu1nkN8QZW-2FRty6rq-2BAOMgLbEuW5SzbokJ7IpthDA-3D Build ID: 642856 Analysis Summary: New defects found: 0 Defects eliminated: 0 From phk at phk.freebsd.dk Mon Sep 23 14:01:59 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Sep 2024 14:01:59 +0000 Subject: Homework for bugwas 2024-09-30 is ticket 3976 Message-ID: <202409231401.48NE1x5a071503@critter.freebsd.dk> In order to improve throughput of bugwashes, I'll start to assign "homework" for then, tickets which everybody is expected to be ready to handle. For next week, the homework is ticket 3976: Pluggable Acceptors. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Tue Sep 24 12:47:30 2024 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 24 Sep 2024 12:47:30 +0000 Subject: Homework for bugwas 2024-09-30 is ticket 3976 In-Reply-To: <202409231401.48NE1x5a071503@critter.freebsd.dk> References: <202409231401.48NE1x5a071503@critter.freebsd.dk> Message-ID: On Mon, Sep 23, 2024 at 2:02?PM Poul-Henning Kamp wrote: > > In order to improve throughput of bugwashes, I'll start to assign > "homework" for then, tickets which everybody is expected to be > ready to handle. > > For next week, the homework is ticket 3976: Pluggable Acceptors. I have relayed this to Asad and the rest of the team on our end. Dridi From scan-admin at coverity.com Mon Sep 30 08:18:11 2024 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 30 Sep 2024 08:18:11 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <66fa5ec229a2d_3520762ac9b6e7b9a44939f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu6BUNirv33lqHGQsDVQ-2BP2tg6QNq2-2FpfeAVxnw32Pj2zw-3D-3DIcOo_yQhjbMw4LeDZMA4nqwf-2BPKRH1TcZpi4LlAZWuGRhHR3k7QQOhDsxOsL24eOVyTiQ4s91H1oa-2BRO4wBm12FW3reLRL-2FaRn90-2Fnk3EC0lOia4zkP1PzAeJt1hKBtdB6FwuhHfEAHWnbyhV76BsqGCwlnygMuWdewtqgdV0P-2Fx-2FbisfN1bOD-2B5-2BVC76j0LsCYhgp3m8G-2FjdWpwN0phfURSXGfWSu5-2BzKPA3I06mZJdWl3Y-3D Build ID: 644372 Analysis Summary: New defects found: 0 Defects eliminated: 0 From phk at phk.freebsd.dk Mon Sep 30 13:45:26 2024 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 30 Sep 2024 13:45:26 +0000 Subject: Bugwash homework for 2024-10-07: #3528 Message-ID: <202409301345.48UDjQEP074969@critter.freebsd.dk> This is the "does vut log, first, all or only sent headers" question. Please come prepared -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.