Re: mysql_fdw crash

Поиск
Список
Период
Сортировка
От Mithun Cy
Тема Re: mysql_fdw crash
Дата
Msg-id CAD__Oui_5L+YLd=GoZVRkGCKkouhj1g0MnM_K=xB6UN46i7mNw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: mysql_fdw crash  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: mysql_fdw crash  (066ce286@free.fr)
Список pgsql-hackers
On Tue, Nov 20, 2018 at 7:59 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> On 11/20/18 3:06 PM, 066ce286@free.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: CF app feature request
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Connection slots reserved for replication