Re: win_flex.exe (and likely win_bison.exe) isn't concurrency safe

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: win_flex.exe (and likely win_bison.exe) isn't concurrency safe
Date: 2022-09-03 05:03:43
Message-ID: CAA4eK1LJb6UguhAB6wrXhu1eNhsm_OObFd621F1yDzwNbmhTDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 3, 2022 at 4:13 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> building PG with meson on windows I occasionally got weird errors around
> scanners. Sometimes scanner generation would fail with
>
> win_flex.exe: error deleting file C:\Users\myadmin\AppData\Local\Temp\~flex_out_main_2
>
> sometimes the generated scanner would just be corrupted.
>
>
> I was confused by only hitting this in local VM, not in CI, but after finally
> hunting it down it made more sense:
> https://github.com/lexxmark/winflexbison/issues/86
>
> https://github.com/lexxmark/winflexbison/blob/master/flex/src/main.c#L1051
>
> It uses a temporary file name without any concurrency protection. Looks like
> windows' _tempnam is pretty darn awful and returns a predictable name as long
> as no conflicting file exists.
>
> Our documentation doesn't point to winflexbison, but recommends using
> flex/bison from msys. But I've certainly read about others using winflexbison,
> e.g. [1] [2]. The flex/bison in 'chocolatey', which I've also seen referenced,
> is afaics winflexbison.
>
>
> Afaict the issue also exists in our traditional windows build - but I've not
> seen anybody report this as an issue.
>
>
> I started this thread to document the issue, in case developers using visual
> studio are hitting this today.
>

I regularly use visual studio for the development work but never hit
this issue probably because I am using flex/bison from msys.

>
> It looks like a similar issue exists for the windows bison port:
> https://github.com/lexxmark/winflexbison/blob/b2a94ad5fd82cf4a54690a879e14ff9511b77273/bison/src/output.c#L816
>
> I've not observed that failure, presumably because the window for it is much
> shorter.
>
>
> For the meson build it is trivial to "address" this by setting FLEX_TMP_DIR to
> a private directory (which we already need to deal with lex.backup), something
> similar could be done for src/tools/msvc.
>
>
> Unless we think it'd be better to just refuse to work with winflexbison?
>

Personally, I have never used this but I feel it would be good to keep
it working especially if others are using it.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-09-03 05:21:51 Re: win_flex.exe (and likely win_bison.exe) isn't concurrency safe
Previous Message Amit Kapila 2022-09-03 04:43:49 Re: test_decoding assertion failure for the loss of top-sub transaction relationship