Re: BUG #16176: NULL value returned by category_sql argument to crosstab() causes segmentation fault
Joe Conway <[email protected]> Mon, 23 Dec 2019 13:40:34 -0500
| Newsgroups | gmane.comp.db.postgresql.bugs |
|---|---|
| Message-ID | <[email protected]> |
On 12/21/19 10:08 AM, Tom Lane wrote: > Joe Conway <[email protected]> writes: >> It appears that in pg11 (and presumably prior) when snprintf() is called >> it is resolved (here at least )to __GI___snprintf() which comes directly >> from libc. On my desktop machine the system snprintf() deals with a null >> pointer argument without crashing. I guess this is why the crash was >> platform dependent. > > Right, glibc's version of snprintf has produced "(nil)" or "(null)" > or something like that for many years. I'm not sure if that's true > among the BSDen. One place where the platform snprintf does *not* > survive this case is Windows. > >> In pg12 (and presumably master), it is resolved to our own port function >> pg_snprintf(), which in turn works its way to dopr(), where strlen() is >> called on a null pointer and "<boom>". > > Right. While it would only take a couple more lines of code to act like > glibc does, we intentionally adopted the stricter definition because it > seemed more likely to expose bugs. Looks like it just did. > >> From what I can see, even on pg11 and prior, having a null category >> never did anything useful. And in the 16 years or so since this has been >> around, no one in my memory ever asked for that functionality, so I am >> inclined to refuse NULL category values unless someone wants to make a >> good case otherwise. > > WFM, but I've never used crosstab() much so I don't have a good feeling > for significant use-cases. Pushed that way to all supported branches. If someone arrives with a compelling use-case, the changes would likely not be something we would want to back patch, so we can address it if/when that happens. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEg14x9eymXoJyHrH+N/L3QzX32GUFAl4BCiIACgkQN/L3QzX3 2GUl5Q//dkuxuO9DLnA4iqhofk46Hwju5yRKAATZZpg5oKaQDG6XWpICVOhrR3nn AI+ICWrA37ZB9/Xa6zL5ALtsUp2xsDAN+viyTglBdjWcFGW30p1Ew118bBaJeUOg yrVeuI0ifAK+jY+RgSj7kJzCUQXRRWXlGn7BBqwiaAbRsPbBXp4BgRJIGXy1dKsc i19bvCadcV58PW5ksOBnqNcKje3wyeFntrLB1y5CHp6C/VyG8ynfzKvHVjmUkhcM 52V2l+Qjqk+DcNgvSHujngolOA7AxrCg9cVClk0m6HclGZAxZKWD9livu6U1wXc6 urFlKn6wATKQQ4nTCdOCdFODh+xMyBiaziRpj7jBRVT6GAoD1myowwks0/b+J1c6 YGb8TigM4pO6E9kg5RSuTe6y9xRYQ+6ZuCBCCHDaekzLGsJXr2JTb/yebsekUxF4 MjXA7fiUHKe39W49E+Ch6FSn0Uc1B6t6314rdzxz7f3xP7bFS975tVunctsVWxSZ oDI9NpD2XDhPIpl/whbu3w8ioxWj3JUliUfMvjztNtCp4IZv1sEZxaLaN45e8YvO r8tJOilZ69tDRuS1LrorjlkRTTZXiGiJdJs75odH35Snbmpo4HMzrEkvjHg6APiO XKt6+xCvWbpmME17Azbu2O/oUGOeEaTls8AKRnqODu9vVLBXykk= =9X9u -----END PGP SIGNATURE-----