okbob / plpgsql_check

plpgsql_check is a linter tool (does source code static analyze) for the PostgreSQL language plpgsql (the native language for PostgreSQL store procedures).
https://groups.google.com/forum/#!forum/postgresql-extensions-hacking
Other
625 stars 52 forks source link

Crash on 9.5: Failed process was running: select * from plpgsql_check_function('dyn_sql_3'); #67

Closed df7cb closed 4 years ago

df7cb commented 4 years ago

Hi, we are working on getting plpgsql_check into Debian. Unfortunately the latest 1.11.0 release crashes:

13:29:33 9.5 regress 5432 online postgres /tmp/pg_virtualenv.UeAhNP/data/9.5/regress /tmp/pg_virtualenv.UeAhNP/log/postgresql-9.5-regress.log
13:29:34 ============== running regression test queries        ==============
13:29:34 test plpgsql_check_passive    ... ok
13:29:34 test plpgsql_check_active     ... FAILED (test process exited with exit code 2)
13:29:34 test plpgsql_check_active-9.5 ... FAILED (test process exited with exit code 2)
13:29:34 test plpgsql_check_passive-9.5 ... ok

13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression ERROR:  could not identify column "a" in record data type at character 8
13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression QUERY:  select $1.a + $1.b
13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression CONTEXT:  PL/pgSQL function dyn_sql_2() line 8 at EXECUTE
13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression STATEMENT:  select dyn_sql_2();
13:29:34 2020-07-17 11:29:34.360 UTC [6928] LOG:  server process (PID 6978) was terminated by signal 11: Segmentation fault
13:29:34 2020-07-17 11:29:34.360 UTC [6928] DETAIL:  Failed process was running: select * from plpgsql_check_function('dyn_sql_3');
13:29:34 2020-07-17 11:29:34.360 UTC [6928] LOG:  terminating any other active server processes

This is on 9.5. (I don't know if other versions are affected, our testsuite tries 9.5 first and stops there.)

Full build log: https://pgdgbuild.dus.dg-i.net/job/plpgsql-check-binaries/2/architecture=amd64,distribution=sid/consoleFull

df7cb commented 4 years ago

Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055ba7d09a44f in SPI_freeplan ()
#0  0x000055ba7d09a44f in SPI_freeplan ()
No symbol table info available.
#1  0x00007f3e027a5994 in release_exprs (exprs=<optimized out>) at src/check_function.c:1261
        expr = 0x7ffc6e1bc430
        l = 0x55ba7ee5d8b0
#2  0x00007f3e027a6b00 in plpgsql_check_function_internal (ri=ri@entry=0x7ffc6e1bd370, cinfo=cinfo@entry=0x7ffc6e1bd3a0) at src/check_function.c:262
        edata = 0x55ba7ee5db40
        save_exception_stack = 0x7ffc6e1bdaf0
        save_context_stack = 0x0
        local_sigjmp_buf = {{__jmpbuf = {140722155803552, -1217440526476803945, 140722155803504, 140722155803888, 140722155803504, 0, 1216557376636551319, 1253914664073527447}, __mask_was_saved = 0, __saved_mask = {__val = {94259480748720, 844433520066561, 11607211431193953792, 5390183972864, 72057594037927936, 1, 11607211431193953792, 94259478062240, 139904305943688, 1, 94259478064312, 94259478062240, 1243445984, 94259480989552, 96, 94259480989552}}}}
        cstate = {argnames = 0x0, decl_volatility = 118 'v', volatility = 105 'i', has_execute_stmt = 1 '\001', skip_volatility_check = 0 '\000', estate = 0x7ffc6e1bcdf0, check_cxt = 0x55ba7ee7c970, exprs = 0x55ba7ee5d7f0, is_active_mode = 1 '\001', used_variables = 0x0, modif_variables = 0x55ba7eeaf888, top_stmt_stack = 0x0, found_return_query = 0 '\000', found_return_dyn_query = 0 '\000', func_oids = 0x0, rel_oids = 0x0, fake_rtd = 0 '\000', result_info = 0x7ffc6e1bd370, cinfo = 0x7ffc6e1bd3a0, safe_variables = 0x0, out_variables = 0x0, protected_variables = 0x55ba7ee5d718, auto_variables = 0x55ba7ee5d738, stop_check = 0 '\000', allow_mp = 1 '\001', has_mp = 0 '\000'}
        function = 0x55ba7eec5d58
        save_nestlevel = 0
        reload_config = <optimized out>
        fake_fcinfo_data = {flinfo = 0x7ffc6e1bcc60, context = 0x0, resultinfo = 0x7ffc6e1bccc0, fncollation = 0, isnull = 0 '\000', nargs = 0, arg = {0 <repeats 100 times>}, argnull = '\000' <repeats 99 times>}
        fake_fcinfo = 0x7ffc6e1bcf80
        flinfo = {fn_addr = 0x0, fn_oid = 16650, fn_nargs = 0, fn_strict = 0 '\000', fn_retset = 0 '\000', fn_stats = 0 '\000', fn_extra = 0x55ba7eec5d58, fn_mcxt = 0x55ba7ee05e58, fn_expr = 0x0}
        trigdata = {type = T_SpecialJoinInfo, tg_event = 179, tg_relation = 0x7c00000070, tg_trigtuple = 0x2, tg_newtuple = 0x770000006b, tg_trigger = 0x10, tg_trigtuplebuf = 0, tg_newtuplebuf = 0}
        etrigdata = {type = 1847315568, event = 0x7f3e0e2a3be0 "\220\235\354~\272U", parsetree = 0x20c, tag = 0x7 <error: Cannot access memory at address 0x7>}
        tg_trigger = {tgoid = 0, tgname = 0x0, tgfoid = 0, tgtype = 0, tgenabled = 0 '\000', tgisinternal = 0 '\000', tgconstrrelid = 0, tgconstrindid = 87296, tgconstraint = 16650, tgdeferrable = 0 '\000', tginitdeferred = 0 '\000', tgnargs = 0, tgnattr = -16565, tgattr = 0x55ba7eb4f788, tgargs = 0x55ba7d2a5440 <FunctionCall2Coll+112>, tgqual = 0x7ffc6e1bd140 ""}
        rc = <optimized out>
        oldowner = 0x55ba7eb9a7e0
        cur_estate = 0x0
        old_cxt = 0x55ba7ee05e58
        estate = {func = 0x55ba7eec5d58, retval = 0, retisnull = 1 '\001', rettype = 0, fn_rettype = 2278, retistuple = 0 '\000', retisset = 0 '\000', readonly_func = 0 '\000', rettupdesc = 0x0, exitlabel = 0x0, cur_error = 0x0, tuple_store = 0x0, tuple_store_cxt = 0x55ba7ee05e58, tuple_store_owner = 0x55ba7ed3ee78, rsi = 0x7ffc6e1bccc0, found_varno = 0, ndatums = 4, datums = 0x55ba7ee5d688, paramLI = 0x7f3e02754f88, simple_eval_estate = 0x55ba7eb4e638, cast_hash = 0x1e0173eb, cast_hash_context = 0x7ffc6e1bcfd0, eval_tuptable = 0x0, eval_processed = 0, eval_lastoid = 0, eval_econtext = 0x0, err_stmt = 0x55ba7ee7b038, err_text = 0x0, plugin_info = 0x0}
        rsinfo = {type = T_ReturnSetInfo, econtext = 0x55ba7ee6cdb8, expectedDesc = 0x55ba7ee6cca0, allowedModes = 3, returnMode = SFRM_ValuePerCall, isDone = ExprSingleResult, setResult = 0x0, setDesc = 0x0}
        fake_rtd = 0 '\000'
        __func__ = "plpgsql_check_function_internal"
#3  0x00007f3e027b08b1 in check_function_internal (fnoid=<optimized out>, fcinfo=<optimized out>) at src/tablefunc.c:162
        cinfo = {proctuple = 0x7f3e02755b18, is_procedure = 0 '\000', fn_oid = 16650, rettype = 2278, volatility = 118 'v', relid = 0, anyelementoid = 23, anyenumoid = 0, anyrangeoid = 3904, anycompatibleoid = 23, anycompatiblerangeoid = 3904, trigtype = PLPGSQL_NOT_TRIGGER, src = 0x0, fatal_errors = 1 '\001', other_warnings = 1 '\001', performance_warnings = 0 '\000', extra_warnings = 1 '\001', security_warnings = 0 '\000', show_profile = 0 '\000', oldtable = 0x0, newtable = 0x0}
        ri = {format = 1, tuple_store = 0x55ba7ee53ff0, tupdesc = 0x55ba7ee53ed8, sinfo = 0x0, init_tag = 0 '\000'}
        rsinfo = 0x7ffc6e1bd4f0
        prev_errorcontext = 0x0
        format = 1
        __func__ = "check_function_internal"
#4  0x000055ba7d077135 in ExecMakeTableFunctionResult ()
No symbol table info available.
#5  0x000055ba7d08e200 in ?? ()
No symbol table info available.
#6  0x000055ba7d079219 in ExecScan ()
No symbol table info available.
#7  0x000055ba7d071358 in ExecProcNode ()
No symbol table info available.
#8  0x000055ba7d06dd2f in standard_ExecutorRun ()
No symbol table info available.
#9  0x000055ba7d199067 in ?? ()
No symbol table info available.
#10 0x000055ba7d19a798 in PortalRun ()
No symbol table info available.
#11 0x000055ba7d1977ef in PostgresMain ()
No symbol table info available.
#12 0x000055ba7d12c518 in ?? ()
No symbol table info available.
#13 0x000055ba7d12d2bb in PostmasterMain ()
No symbol table info available.
#14 0x000055ba7ced9a50 in main ()
No symbol table info available.
okbob commented 4 years ago

pá 17. 7. 2020 v 13:36 odesílatel Christoph Berg notifications@github.com napsal:

Hi, we are working on getting plpgsql_check into Debian. Unfortunately the latest 1.11.0 release crashes:

13:29:33 9.5 regress 5432 online postgres /tmp/pg_virtualenv.UeAhNP/data/9.5/regress /tmp/pg_virtualenv.UeAhNP/log/postgresql-9.5-regress.log 13:29:34 ============== running regression test queries ============== 13:29:34 test plpgsql_check_passive ... ok 13:29:34 test plpgsql_check_active ... FAILED (test process exited with exit code 2) 13:29:34 test plpgsql_check_active-9.5 ... FAILED (test process exited with exit code 2) 13:29:34 test plpgsql_check_passive-9.5 ... ok

13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression ERROR: could not identify column "a" in record data type at character 8 13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression QUERY: select $1.a + $1.b 13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression CONTEXT: PL/pgSQL function dyn_sql_2() line 8 at EXECUTE 13:29:34 2020-07-17 11:29:34.354 UTC [6978] postgres@contrib_regression STATEMENT: select dyn_sql_2(); 13:29:34 2020-07-17 11:29:34.360 UTC [6928] LOG: server process (PID 6978) was terminated by signal 11: Segmentation fault 13:29:34 2020-07-17 11:29:34.360 UTC [6928] DETAIL: Failed process was running: select * from plpgsql_check_function('dyn_sql_3'); 13:29:34 2020-07-17 11:29:34.360 UTC [6928] LOG: terminating any other active server processes

This is on 9.5. (I don't know if other versions are affected, our testsuite tries 9.5 first and stops there.)

Full build log: https://pgdgbuild.dus.dg-i.net/job/plpgsql-check-binaries/2/architecture=amd64,distribution=sid/consoleFull

It is working on my Fedora Comp. Please, can you send me a version of the used debian? It should to work on some older UBUNTU too

https://travis-ci.com/github/okbob/plpgsql_check/jobs/361185259

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/67, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO42DS5OPTZRQAJHQ2W3R4AZUBANCNFSM4O6DHLOA .

df7cb commented 4 years ago

It's crashing on Debian unstable/amd64.

okbob commented 4 years ago

pá 17. 7. 2020 v 15:19 odesílatel Christoph Berg notifications@github.com napsal:

It's crashing on Debian unstable/amd64.

I am not an expert on Debian, please help. I have a fresh Debian SID.

When I try to install Postgres 9.5 from pgdg a installation fails

Depends on libc6 (>= 2.29) but 2.28 is installed

You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/67#issuecomment-660102777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO444HG23HOY5HCOYDELR4BFUXANCNFSM4O6DHLOA .

df7cb commented 4 years ago

2.28 is buster (stable), sid (unstable) has 2.31, so what you have is either not unstable, or a very old version.

The problem is visible on buster as well with 9.5, though.

okbob commented 4 years ago

pá 17. 7. 2020 v 16:27 odesílatel Christoph Berg notifications@github.com napsal:

2.28 is buster (stable), sid (unstable) has 2.31, so what you have is either not unstable, or a very old version.

The problem is visible on buster as well with 9.5, though.

Unfortunately, I cannot reproduce this issue.

pavel@debian:~/src/plpgsql_check$ uname -a Linux debian 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux pavel@debian:~/src/plpgsql_check$ uname -r 5.7.0-1-amd64

pavel@debian:~/src/plpgsql_check$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux bullseye/sid Release: stable-updates Codename: sid

pavel@debian:~$ apt list --installed | grep postgres

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

postgresql-9.5-dbg/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed] postgresql-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed] postgresql-client-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed,automatic] postgresql-client-common/sid-pgdg,now 215.pgdg+1 all [installed,automatic] postgresql-common/sid-pgdg,now 215.pgdg+1 all [installed,automatic] postgresql-contrib-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed,automatic] postgresql-server-dev-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed]

pavel@debian:~/src/plpgsql_check$ git branch

pavel@debian:~/src/plpgsql_check$ sudo make install /bin/mkdir -p '/usr/lib/postgresql/9.5/lib' /bin/mkdir -p '/usr/share/postgresql/9.5/extension' /bin/mkdir -p '/usr/share/postgresql/9.5/extension' /usr/bin/install -c -m 755 plpgsql_check.so '/usr/lib/postgresql/9.5/lib/plpgsql_check.so' /usr/bin/install -c -m 644 .//plpgsql_check.control '/usr/share/postgresql/9.5/extension/' /usr/bin/install -c -m 644 .//plpgsql_check--1.11.sql '/usr/share/postgresql/9.5/extension/' pavel@debian:~/src/plpgsql_check$ make installcheck /usr/lib/postgresql/9.5/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=./ --bindir='/usr/lib/postgresql/9.5/bin' --dbname=pl_regression --dbname=contrib_regression plpgsql_check_passive plpgsql_check_active plpgsql_check_active-9.5 plpgsql_check_passive-9.5 (using postmaster on Unix socket, default port) ============== dropping database "contrib_regression" ============== DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test plpgsql_check_passive ... ok test plpgsql_check_active ... ok test plpgsql_check_active-9.5 ... ok test plpgsql_check_passive-9.5 ... ok

===================== All 4 tests passed.

Can you check other older releases or master branch?

Maybe is some wrong in your build environment

Can you install debug symbols for Postgres Server?

Regards

Pavel

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/67#issuecomment-660137303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO46PMNEKYSFQMIMCG7LR4BNWZANCNFSM4O6DHLOA .

okbob commented 4 years ago

please, can you check 1.11.1 release?

I fixed a warning

Regards

Pavel

okbob commented 4 years ago

so 18. 7. 2020 v 9:30 odesílatel Pavel Stehule pavel.stehule@gmail.com napsal:

pá 17. 7. 2020 v 16:27 odesílatel Christoph Berg notifications@github.com napsal:

2.28 is buster (stable), sid (unstable) has 2.31, so what you have is either not unstable, or a very old version.

The problem is visible on buster as well with 9.5, though.

Unfortunately, I cannot reproduce this issue.

pavel@debian:~/src/plpgsql_check$ uname -a Linux debian 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux pavel@debian:~/src/plpgsql_check$ uname -r 5.7.0-1-amd64

pavel@debian:~/src/plpgsql_check$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux bullseye/sid Release: stable-updates Codename: sid

pavel@debian:~$ apt list --installed | grep postgres

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

postgresql-9.5-dbg/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed] postgresql-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed] postgresql-client-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed,automatic] postgresql-client-common/sid-pgdg,now 215.pgdg+1 all [installed,automatic] postgresql-common/sid-pgdg,now 215.pgdg+1 all [installed,automatic] postgresql-contrib-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed,automatic] postgresql-server-dev-9.5/sid-pgdg,now 9.5.22-1.pgdg+1 amd64 [installed]

pavel@debian:~/src/plpgsql_check$ git branch

  • (HEAD detached at v1.11.0) master

pavel@debian:~/src/plpgsql_check$ sudo make install /bin/mkdir -p '/usr/lib/postgresql/9.5/lib' /bin/mkdir -p '/usr/share/postgresql/9.5/extension' /bin/mkdir -p '/usr/share/postgresql/9.5/extension' /usr/bin/install -c -m 755 plpgsql_check.so '/usr/lib/postgresql/9.5/lib/plpgsql_check.so' /usr/bin/install -c -m 644 .//plpgsql_check.control '/usr/share/postgresql/9.5/extension/' /usr/bin/install -c -m 644 .//plpgsql_check--1.11.sql '/usr/share/postgresql/9.5/extension/' pavel@debian:~/src/plpgsql_check$ make installcheck /usr/lib/postgresql/9.5/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=./ --bindir='/usr/lib/postgresql/9.5/bin' --dbname=pl_regression --dbname=contrib_regression plpgsql_check_passive plpgsql_check_active plpgsql_check_active-9.5 plpgsql_check_passive-9.5 (using postmaster on Unix socket, default port) ============== dropping database "contrib_regression" ============== DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test plpgsql_check_passive ... ok test plpgsql_check_active ... ok test plpgsql_check_active-9.5 ... ok test plpgsql_check_passive-9.5 ... ok

===================== All 4 tests passed.

Can you check other older releases or master branch?

Maybe is some wrong in your build environment

It fails when I run tests via autopkg tests. When I run tests manually, it is working.

Can you install debug symbols for Postgres Server?

Regards

Pavel

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/67#issuecomment-660137303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO46PMNEKYSFQMIMCG7LR4BNWZANCNFSM4O6DHLOA .

okbob commented 4 years ago

I found a error - please check https://github.com/okbob/plpgsql_check/releases/tag/v1.11.2

In my environment all tests started by autopkg are ok now.

df7cb commented 4 years ago

Thanks for the fix.

Unfortunately, now that the unstable/amd64 build has passed, a new problem popped up that affects all distributions: on 32-bit (i386), there is a regression diff:

19:28:01 --- /tmp/autopkgtest.qvlKvK/tree/expected/plpgsql_check_active_3.out   2020-07-18 13:05:51.000000000 +0000
19:28:01 +++ /tmp/autopkgtest.qvlKvK/tree/results/plpgsql_check_active.out  2020-07-18 17:28:00.659390710 +0000
19:28:01 @@ -7209,7 +7209,10 @@
19:28:01  end;
19:28:01  $$ language plpgsql;
19:28:01  select * from plpgsql_check_function('f');
19:28:01 - plpgsql_check_function 
19:28:01 -------------------------
19:28:01 -(0 rows)
19:28:01 +                           plpgsql_check_function                           
19:28:01 +----------------------------------------------------------------------------
19:28:01 + error:55000:8:RAISE:record "r2" is not assigned yet
19:28:01 + Detail: The tuple structure of a not-yet-assigned record is indeterminate.
19:28:01 + Context: SQL statement "SELECT r2.a"
19:28:01 +(3 rows)

https://pgdgbuild.dus.dg-i.net/job/plpgsql-check-binaries/4/architecture=i386,distribution=sid/console https://pgdgbuild.dus.dg-i.net/job/plpgsql-check-binaries/4/

Again, this is with 9.5 because that's the first what the testsuite tries. (12 seems fine; I didn't try the versions inbetween.)

okbob commented 4 years ago

please, try 1.11.3

df7cb commented 4 years ago

Everything green now. Thanks!

okbob commented 4 years ago

ne 19. 7. 2020 v 17:43 odesílatel Christoph Berg notifications@github.com napsal:

Everything green now. Thanks!

super :)

I thank you for your work

Pavel

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/67#issuecomment-660665600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO42SNZLNNWKZBWLHJFDR4MIAZANCNFSM4O6DHLOA .