[BUG][PATCH] ecpg crash with bytea type and cursors - Mailing list pgsql-bugs

From Jehan-Guillaume de Rorthais
Subject [BUG][PATCH] ecpg crash with bytea type and cursors
Date
Msg-id 20200630153008.3e73d3da@firost
Whole thread Raw
Responses Re: [BUG][PATCH] ecpg crash with bytea type and cursors
List pgsql-bugs
Hi,

A customer reported to us a crash of ecpg when using bytea as variable of
cursors.

Please, find in attachment a patch adding a regression test reproducing the
crash: v1-0001-Add-ecpg-test-on-using-bytea-as-cursor-variable.patch

Here is the backtrace:

  #0  0x0000564aaeeed3f4 in adjust_outofscope_cursor_vars
      (cur=cur@entry=0x564aaff25630) at preproc.y:296 
  #1  0x0000564aaef037eb in base_yyparse () at preproc.y:9851
  #2  0x0000564aaeee8945 in main (argc=2, argv=0x7ffeb5ddb108) at ecpg.c:458

According to documentation and source, the bytea type is supposed to be handled
as the varchar type. However, the original patch 050710b3696 miss to add to
adjust_outofscope_cursor_vars() how to handle bytea type as variable. Because of
this, bytea type was considered as an array of value, leading to the crash
because type->u.element was all NULL. The patch adjust existing code to
considers bytea in the same way varchar is handled. See in attachment patch
v1-0002-Fix-ecpg-crash-with-bytea-and-cursor-variables.patch

But there's something else the patch does not address and that might need to be
adjusted. Existing tests were OK because they don't use cursors AND bytea vars
are declared using a macro to hold their size. Eg.:

  bytea send_buf[2][DATA_SIZE]; # ok
  bytea send_buf[2][512]; # crash !

This is because of this test in adjust_outofscope_cursor_vars() (before the
proposed patch):

    else if ((ptr->variable->type->type != ECPGt_varchar
              && ptr->variable->type->type != ECPGt_char
              && ptr->variable->type->type != ECPGt_unsigned_char
              && ptr->variable->type->type != ECPGt_string)
             && atoi(ptr->variable->type->size) > 1)

This test match and related code crash when the size is given as number because
atoi(size) > 1. When using a macro to hold the size, this test doesn't
match and the fallback else{} code doesn't crash, but it doesn't build the same
variable neither (see indirection before ECPGget_var). I'm not sure how
important it is for bytea/varchar type though. I don't know how to build a test
case producing ECPGget_var for them.

Regards,

Attachment

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #16516: when testing jit get terminate called after throwing an instance of 'std::bad_function_call'
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #16497: old and new pg_controldata WAL segment sizes are invalid or do not match