From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | dr00487751(at)techmahindra(dot)com,pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15704: Possible causes for calling abort () system call during querying database. |
Date: | 2019-03-19 13:36:02 |
Message-ID: | 68d57135-8917-465c-81bd-511d77465fe7@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form wrote:
> (gdb) bt
> #0 0x00007fddc8f664d8 in raise () from /lib64/libc.so.6
> #1 0x00007fddc8f695aa in abort () from /lib64/libc.so.6
> #2 0x00007fddc8fa092b in ?? () from /lib64/libc.so.6 -> Not sure which
> function is called by realloc in the postgres software
> #3 0x00007fddc8faa906 in ?? () from /lib64/libc.so.6 -> Not sure which
> function is called by realloc in the postgres software
> #4 0x00007fddc8faee7b in realloc () from /lib64/libc.so.6
> #5 0x00007fddcd5eb0fd in pqCheckInBufferSpace () from
> /hegw/postgres/lib/libpq.so.5
realloc() can abort when it finds out that the internal data
structures controlling memory allocations are corrupted.
It should also print an error message to stderr when this
occurs.
This is generally caused by earlier buffer overruns in user
code. The fact that the problem is detected when realloc()
is called from postgres code does not imply that
the problem originates in postgres code.
To locate the bug, it may help to run your application with valgrind.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-03-19 15:30:17 | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |
Previous Message | Jeff Janes | 2019-03-19 13:28:49 | Re: BUG #15704: Possible causes for calling abort () system call during querying database. |