Hi, On 2022-08-24 00:18:27 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2022-08-23 20:36:55 -0700, Andres Freund wrote: > >> Running the ecpg regression tests interactively (to try to find a different > >> issue), triggered a crash on windows due to an uninitialized variable > >> (after > >> pressing "ignore" in that stupid gui window that we've only disabled for > >> the > >> backend). > >> "The variable 'replace_val' is being used without being initialized." > > > Looks to me like that's justified. > > Hmm ... that message sounded like it is a run-time detection not from > static analysis.
Yes, it's a runtime error. > But if the regression tests are triggering use of uninitialized values, how > could we have failed to detect that? Either valgrind or unstable behavior > should have found this ages ago. I think it's just different criteria for when to report issues. Valgrind reports uninitialized memory only when there's a conditional branch depending on it or such. Whereas this seems to trigger when passing an uninitialized value to a function by value, even if it's then not relied upon. I don't think we regularly test all client tests with valgrind, btw. Skink only runs the server under valgrind at least. > Seeing that replace_val is a union of differently-sized types, > I was wondering if this message is a false positive based on > struct assignment transferring a few uninitialized bytes, or > something like that. I think it's genuinely uninitialized - if you track what happens if the first parameter is e.g. %X: It'll not initialize replace_val, but then call pgtypes_fmt_replace(). So an uninit value is passed. Greetings, Andres Freund
