Re: [BUGS] [HACKERS] Segmentation fault in libpq
От | Michal Novotny |
---|---|
Тема | Re: [BUGS] [HACKERS] Segmentation fault in libpq |
Дата | |
Msg-id | 2a0f743f-4d96-30b1-8b5d-86541e8bcb34@greycortex.com обсуждение исходный текст |
Ответ на | Re: [BUGS] [HACKERS] Segmentation fault in libpq (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-bugs |
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.novotny@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? Thanks, Michal -- Michal Novotny System Development Lead michal.novotny@greycortex.com GREYCORTEX s.r.o. Purkynova 127, 61200 Brno Czech Republic www.greycortex.com
В списке pgsql-bugs по дате отправления: