Обсуждение: psql crashes found when executing slash commands
Hi,
We recently upgraded to Postgres 9.6.8 version.
After the upgrade we are encountering crash for psql and it is happening only when we are executing “slash” commands.
Example:
template1=# create database tempora;
CREATE DATABASE
template1=# \c tempora
Segmentation fault (core dumped)
template1=# create table tmp (emp int);
CREATE TABLE
template1=# select count(*) from tmp;
count
-------
0
(1 row)
template1=# \l
Segmentation fault (core dumped)
Below is the backtrace:
(gdb) bt
#0 0x0000000120037a6c in slash_yylex ()
#1 0x0000000120038d04 in psql_scan_slash_command ()
Backtrace stopped: frame did not save the PC
(gdb) bt full
#0 0x0000000120037a6c in slash_yylex ()
No symbol table info available.
#1 0x0000000120038d04 in psql_scan_slash_command ()
No symbol table info available.
Backtrace stopped: frame did not save the PC
Regards,
Sandhya
Hello Hmm. What operating system are you using? Hardware architecture? Do you compile postgresql yourself or install some precompiledpackages? We have tests for psql slash-commands and they are not broken. regards, Sergei
On Wed, Jun 06, 2018 at 10:42:41AM +0300, Sergei Kornilov wrote: > Hmm. What operating system are you using? Hardware architecture? Do > you compile postgresql yourself or install some precompiled packages? > We have tests for psql slash-commands and they are not broken. My bet is on an issue with the version of flex used for compilation, and that those binaries have been manually compiled. -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jun 06, 2018 at 10:42:41AM +0300, Sergei Kornilov wrote:
>> Hmm. What operating system are you using? Hardware architecture? Do
>> you compile postgresql yourself or install some precompiled packages?
>> We have tests for psql slash-commands and they are not broken.
> My bet is on an issue with the version of flex used for compilation, and
> that those binaries have been manually compiled.
psql does some, um, interesting stuff with sharing lexer state between
separately-built flex lexers. I would not be too surprised if it crashes
if you build psqlscan.l and psqlscanslash.l with different versions of
flex, or perhaps even just different flex switches. So that might be an
avenue to check into.
Another theory is that the OP is using something that's not flex at all,
or is some version we've never seen before, and this coding technique
doesn't work at all with it :-(
regards, tom lane
Hi,
We are using a flavour of Linux internally developed. We are compiling for mips architecture.
We compile postgresql.
We tried compiling for different versions of flex apart from the what is installed and still we are not able to succeed
inthis.
Currently we are using flex version 2.5.37.
Any further suggestion or known issue, please let us know.
Regards,
Sandhya
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, June 06, 2018 8:18 PM
To: Michael Paquier <michael@paquier.xyz>
Cc: Sergei Kornilov <sk@zsrv.org>; K S, Sandhya (Nokia - IN/Bangalore) <sandhya.k_s@nokia.com>;
'pgsql-bugs@postgresql.org'<pgsql-bugs@postgresql.org>
Subject: Re: psql crashes found when executing slash commands
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jun 06, 2018 at 10:42:41AM +0300, Sergei Kornilov wrote:
>> Hmm. What operating system are you using? Hardware architecture? Do
>> you compile postgresql yourself or install some precompiled packages?
>> We have tests for psql slash-commands and they are not broken.
> My bet is on an issue with the version of flex used for compilation, and
> that those binaries have been manually compiled.
psql does some, um, interesting stuff with sharing lexer state between
separately-built flex lexers. I would not be too surprised if it crashes
if you build psqlscan.l and psqlscanslash.l with different versions of
flex, or perhaps even just different flex switches. So that might be an
avenue to check into.
Another theory is that the OP is using something that's not flex at all,
or is some version we've never seen before, and this coding technique
doesn't work at all with it :-(
regards, tom lane
Hi,
The issue was with the version of flex(not sure any issue with flex 2.5.37 version).
We were able to compile with flex version 2.6.4 and it is working without any psql crashes.
Thanks for all the help!
Sandhya
-----Original Message-----
From: K S, Sandhya (Nokia - IN/Bangalore)
Sent: Monday, June 11, 2018 11:14 AM
To: 'Tom Lane' <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>
Cc: Sergei Kornilov <sk@zsrv.org>; 'pgsql-bugs@postgresql.org' <pgsql-bugs@postgresql.org>
Subject: RE: psql crashes found when executing slash commands
Hi,
We are using a flavour of Linux internally developed. We are compiling for mips architecture.
We compile postgresql.
We tried compiling for different versions of flex apart from the what is installed and still we are not able to succeed
inthis.
Currently we are using flex version 2.5.37.
Any further suggestion or known issue, please let us know.
Regards,
Sandhya
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, June 06, 2018 8:18 PM
To: Michael Paquier <michael@paquier.xyz>
Cc: Sergei Kornilov <sk@zsrv.org>; K S, Sandhya (Nokia - IN/Bangalore) <sandhya.k_s@nokia.com>;
'pgsql-bugs@postgresql.org'<pgsql-bugs@postgresql.org>
Subject: Re: psql crashes found when executing slash commands
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jun 06, 2018 at 10:42:41AM +0300, Sergei Kornilov wrote:
>> Hmm. What operating system are you using? Hardware architecture? Do
>> you compile postgresql yourself or install some precompiled packages?
>> We have tests for psql slash-commands and they are not broken.
> My bet is on an issue with the version of flex used for compilation, and
> that those binaries have been manually compiled.
psql does some, um, interesting stuff with sharing lexer state between
separately-built flex lexers. I would not be too surprised if it crashes
if you build psqlscan.l and psqlscanslash.l with different versions of
flex, or perhaps even just different flex switches. So that might be an
avenue to check into.
Another theory is that the OP is using something that's not flex at all,
or is some version we've never seen before, and this coding technique
doesn't work at all with it :-(
regards, tom lane
"K S, Sandhya (Nokia - IN/Bangalore)" <sandhya.k_s@nokia.com> writes:
> The issue was with the version of flex(not sure any issue with flex 2.5.37 version).
> We were able to compile with flex version 2.6.4 and it is working without any psql crashes.
Interesting. There are many buildfarm members reporting that they
use 2.5.37, and we've not seen any issues there. Maybe there's a
platform-specific bug in it? Or those members are really running
vendor-patched versions rather than straight 2.5.37? (Hard to
believe they'd all have the same patch though.)
I also remain suspicious that you were running only one of psqlscan.l and
psqlscanslash.l through your local flex, and using the tarball-provided
output file for the other. We currently use flex 2.6.1 when creating
tarballs. It's not real hard to believe that there was an ABI break
between 2.5.x and 2.6.x ...
Dunno that it's worth any extra trouble to track it down, though.
regards, tom lane
On Wed, Jun 13, 2018 at 10:33:38AM -0400, Tom Lane wrote: > Dunno that it's worth any extra trouble to track it down, though. Nah, that's not. Large corporates can be very imaginative when it comes to reinvent packaging concepts again and again. -- Michael