psql crash while executing core regression tests
hi
During installation from source code, there are many crashes for psql while executing core regression tests, all the crashes are similar, the backtrace info as follows:
Core was generated by 'psql'.
Program terminated with signal 11, Segmentation fault.
# 0 0x000000000043f140 in slash_yylex()
(gdb) bt
#0 0x000000000043f140 in slash_yylex()
#1 0x00000000004430fc in psql_scan_slash_command()
#2 0x000000000043f140 in HandleSlashCmds()
#3 0x000000000043f140 in MainLoop()
#4 0x000000000043f140 in main()
I did more compared testing about this scenario, as follows:
1. install from local source code(xxx.tar.gz)
1) switch to source tree directory, and build there ---- no crash generated
2) create a build directory, and build there ---- no crash generated
2. install from git source code
1) switch to source tree directory, and build there ---- no crash generated
2) create a build directory, and build there ---- many crashes generated, but if install newer version of flex, e.g. 2.6.4, the problem doesn't exist. Any suggestions about this behavior?
NOTES:
test commands are same, as follows:
configure --enable-coverage --enable-tap-tests
make
make check
testing environment:
PostgreSQL: 13.2
redhat 7.4, 3.10.0-693.e17.x86_64
flex: 2.5.37
thanks
walker
I use CentOS 7 with flex 2.5.37 quite extensively have never come across a
psql crash. This seems more like an environment related issue on your
system.
On Tue, Mar 2, 2021 at 1:53 PM walker <failaway@qq.com> wrote:
Show quoted text
hi
During installation from source code, there are many crashes for psql
while executing core regression tests, all the crashes are similar, the
backtrace info as follows:Core was generated by 'psql'.
Program terminated with signal 11, Segmentation fault.
# 0 0x000000000043f140 in slash_yylex()
(gdb) bt
#0 0x000000000043f140 in slash_yylex()
#1 0x00000000004430fc in psql_scan_slash_command()
#2 0x000000000043f140 in HandleSlashCmds()
#3 0x000000000043f140 in MainLoop()
#4 0x000000000043f140 in main()I did more compared testing about this scenario, as follows:
1. install from local source code(xxx.tar.gz)
1) switch to source tree directory, and build there ---- no crash
generated
2) create a build directory, and build there ---- no crash generated2. install from git source code
1) switch to source tree directory, and build there ---- no crash generated
2) create a build directory, and build there ---- many crashes generated,
but if install newer version of flex, e.g. 2.6.4, the problem doesn't
exist. Any suggestions about this behavior?NOTES:
test commands are same, as follows:
configure --enable-coverage --enable-tap-tests
make
make checktesting environment:
PostgreSQL: 13.2
redhat 7.4, 3.10.0-693.e17.x86_64
flex: 2.5.37thanks
walker
Hamid Akhtar <hamid.akhtar@gmail.com> writes:
I use CentOS 7 with flex 2.5.37 quite extensively have never come across a
psql crash. This seems more like an environment related issue on your
system.
Yeah ... also, there are more than a dozen buildfarm animals using 2.5.37,
and none of them have shown any sign of distress. We have also got
animals using just about every other flex version under the sun, and they
all work. So I'm inclined to guess that the apparent dependence on flex
version is a mirage, and the real reason why it worked or didn't work is
elsewhere. We don't have enough info here to identify the problem, but
I'd suggest a couple of things:
* make sure you're starting from a completely clean tree ("git clean -dfx"
is your friend)
* avoid changing PATH or other important environment variables between
configure and build
* watch out for conflicts between different PG installations on the same
machine
On the last point, it can be a really bad idea to have any preinstalled
PG programs or libraries on a machine where you're trying to do PG
development. It's too easy to pick up a library out of /usr/lib or a
header out of /usr/include when you wanted to use the version in your
build tree.
Whether any of this explains your problem remains to be seen, but that's
the kind of issue I'd suggest looking for.
regards, tom lane