Re: mysql_fdw crash

From: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, 066ce286(at)free(dot)fr
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mysql_fdw crash
Date: 2018-11-20 17:54:26
Message-ID: CAD__Oui_5L+YLd=GoZVRkGCKkouhj1g0MnM_K=xB6UN46i7mNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 20, 2018 at 7:59 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On 11/20/18 3:06 PM, 066ce286(at)free(dot)fr wrote:
> > Hi,
> >
> >> When gdb will be active, then use command c, and then run query in session. gdb should to catch segfault.
> >
> > Thank you very much. It's been helpfull.
> >
> > BTW behaviour is strange. When I'm executing following, I do have always a SEGV :
> >
> > psql (11.1)
> > Type "help" for help.
> >
> > herve=# CREATE OR REPLACE FUNCTION public.test_bug2(text,integer,timestamp with time zone)
> > herve-# RETURNS integer
> > herve-#
> > herve-# AS '
> > herve'#
> > herve'# select coalesce(max(id),1) from sact_v1.autocalls where label=$1 and machine_id=$2 and created_date=$3;
> > herve'# '
> > herve-# LANGUAGE sql;
> > CREATE FUNCTION
> > herve=# select test_bug2('BSM_CRITICAL_SYSLOG',18843,now());
> >
> > The GDB session :
> >
> > Continuing.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > prepare_query_params (param_types=0x1c86ac8, param_values=0x1c86ac0, param_exprs=0x1c86ab8, param_flinfo=0x1c86ab0, numParams=3, fdw_exprs=0x1c6b5b8, node=0x1c792d8) at mysql_fdw.c:2139
> > 2139 *param_types[i] = exprType(param_expr);
> > (gdb) bt
>
> So which part of that expression triggers the segfault? Try printing the
> different parts, i.e.
>
> p i
> p param_types[i]
>
> It might be helpful to also install the debug package, which would give
> us more readable backtraces.
>
> BTW, considering the failure is in mysql_fdw.c, this very much seems
> like a bug in mysql_fdw - have you tried reporting it through the
> project github repository?
>
> https://github.com/EnterpriseDB/mysql_fdw/issues
>
> That's probably more likely to help, and even if we find a bug here we
> can't really commit that (perhaps some of the mysql_fdw authors are
> watching this list, but I'm not sure about that).

Thanks for reporting,

Oid **param_types)
{
int i;
ListCell *lc;

Assert(numParams > 0);

/* Prepare for output conversion of parameters used in remote query. */
*param_flinfo = (FmgrInfo *) palloc0(sizeof(FmgrInfo) * numParams);

*param_types = (Oid *) palloc0(sizeof(Oid) * numParams);

i = 0;
foreach(lc, fdw_exprs)
{
Node *param_expr = (Node *) lfirst(lc);
Oid typefnoid;
bool isvarlena;

*param_types[i] = exprType(param_expr);

Seems some basic mistake I think it should as below
(*param_types)[i] = exprType(param_expr);

After this it works
postgres=# select test_bug2('BSM_CRITICAL_SYSLOG',18843,now());
test_bug2
-----------
1
(1 row)

--
Thanks and Regards
Mithun Chicklore Yogendra
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-11-20 18:13:03 Re: Connection slots reserved for replication
Previous Message Magnus Hagander 2018-11-20 16:45:20 Re: CF app feature request