On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny <michal.novo...@greycortex.com> wrote: > Hi, > > comments inline ... > > > > On 06/29/2017 03:08 PM, Merlin Moncure wrote: >> >> On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny >> <michal.novo...@greycortex.com> wrote: >>> >>> Hi all, >>> >>> we've developed an application using libpq to access a table in the PgSQL >>> database but we're sometimes experiencing segmentation fault on >>> resetPQExpBuffer() function of libpq called from PQexecParams() with >>> prepared query. >>> >>> PostgreSQL version is 9.6.3 and the backtrace is: >>> >>> Core was generated by `/usr/ti/bin/status-monitor2 -m >>> /usr/lib64/status-monitor2/modules'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 resetPQExpBuffer (str=str@entry=0x9f4a28) at pqexpbuffer.c:152 >>> 152 str->data[0] = '\0'; >>> >>> Thread 1 (Thread 0x7fdf68de3840 (LWP 3525)): >>> #0 resetPQExpBuffer (str=str@entry=0x9f4a28) at pqexpbuffer.c:152 >>> No locals. >>> #1 0x00007fdf66e0333d in PQsendQueryStart (conn=conn@entry=0x9f46d0) at >>> fe-exec.c:1371 >>> No locals. >>> #2 0x00007fdf66e044b9 in PQsendQueryParams (conn=conn@entry=0x9f46d0, >>> command=command@entry=0x409a98 "SELECT min, hour, day, month, dow, >>> sensor, >>> module, params, priority, rt_due FROM sm.cron WHERE sensor = $1 ORDER BY >>> priority DESC", nParams=nParams@entry=1, paramTypes=paramTypes@entry=0x0, >>> paramValues=paramValues@entry=0xa2b7b0, >>> paramLengths=paramLengths@entry=0x0, >>> paramFormats=paramFormats@entry=0x0, resultFormat=resultFormat@entry=0) >>> at >>> fe-exec.c:1192 >>> No locals. >>> #3 0x00007fdf66e0552b in PQexecParams (conn=0x9f46d0, command=0x409a98 >>> "SELECT min, hour, day, month, dow, sensor, module, params, priority, >>> rt_due >>> FROM sm.cron WHERE sensor = $1 ORDER BY priority DESC", nParams=1, >>> paramTypes=0x0, paramValues=0xa2b7b0, paramLengths=0x0, paramFormats=0x0, >>> resultFormat=0) at fe-exec.c:1871 >>> No locals. >>> >>> Unfortunately we didn't have more information from the crash, at least >>> for >>> now. >>> >>> Is this a known issue and can you help me with this one? >> >> Is your application written in C? We would need to completely rule >> out your code (say, by double freeing result or something else nasty) >> before assuming problem was withing libpq itself, particularly in this >> area of the code. How reproducible is the problem? >> >> merlin > > > The application is written in plain C. The issue is it happens just > sometimes - sometimes it happens and sometimes it doesn't. Once it happens > it causes the application crash but as it's systemd unit with > Restart=on-failure flag it's automatically being restarted. > > What's being done is: > 1) Ensure connection already exists and create a new one if it doesn't exist > yet > 2) Run PQexecParams() with specified $params that has $params_cnt elements: > > res = PQexecParams(conn, prepared_query, params_cnt, NULL, (const char > **)params, NULL, NULL, 0); > > 3) Check for result and report error and exit if "PQresultStatus(res) != > PGRES_TUPLES_OK" > 4) Do some processing with the result > 5) Clear result using PQclear() > > It usually works fine but sometimes it's crashing and I don't know how to > investigate further. > > Could you please help me based on information provided above?
You might want to run your code through some analysis tools (for example, valgrind). Short of that, to get help here you need to post the code for review. How big is your application? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
