Re: ecpg assertion on windows

Hi,

On 2022-08-24 00:18:27 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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