Thread: BUG #15704: Possible causes for calling abort () system call during querying database.

The following bug has been logged on the website:

Bug reference:      15704
Logged by:          dheeraj ram
Email address:      dr00487751@techmahindra.com
PostgreSQL version: 9.4.0
Operating system:   Wind River Linux 8.0.0.26
Description:

Hi, 

I am observing process core due to abort () , while querying postgreSQL
database.
Below is my gdb bt trace log: 
(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
#6  0x00007fddcd5eb3cf in pqReadData () from /hegw/postgres/lib/libpq.so.5
#7  0x00007fddcd5e9645 in PQgetResult () from
/hegw/postgres/lib/libpq.so.5
#8  0x00007fddcd5e997a in PQexecFinish () from
/hegw/postgres/lib/libpq.so.5
#9  0x00007fddca576d0d in postgresDBInterface::querry (this=0xe9dfa0,
sqlCMD=...) at postgresDBInterface.cpp:120
#10 0x00007fddca55cef3 in DBwrapperDAO::getDBDAO (this=0xfc4e40, sqlCMD=...)
at DBbasewrapperDAO.cpp:84
#11 0x00007fddca5688a7 in
dbHeNBLocationRegisterInfoDAO::getHeNBLRListbyTAIListAndhmsSlotId
(this=0xfc4e40, pTAIList=0x7fdd9dff5340, numOfTAI=1, hmsSlotId=9 '\t',
    checkFailedPLMN=false, pHeNBLocationRegisterInfo_pLR=0x7fdd9dff4b38,
maxHeNBLR=10000, CountHeNBLR=@0x7fdd9dff4b36: 0) at
dbHeNBLocationRegisterInfoDAO.cpp:1465
#12 0x00007fddcd0ae1fe in HMSSendHandler::HandlePagingMsg (this=0xf05960,
msgBufP=0x7fdd4c003a40) at HMSSendHandler.cpp:419
#13 0x00007fddcd0b1a3e in HMSSendHandler::HandleNonUeAssocMsg
(this=0xf05960, msgBufP=0x7fdd4c003a40, skipOverload=false) at
HMSSendHandler.cpp:757
#14 0x00007fddcd0ac7bc in HMSSendHandler::ProcessMessage (this=0xf05960,
buf=0x7fdd4c003a40, skipOverload=false) at HMSSendHandler.cpp:221
#15 0x00007fddcd0ac176 in HMSSendHandler::ReceiveMesaage (this=0xf05960) at
HMSSendHandler.cpp:164
#16 0x00007fddcd0b39eb in HMSSendHandler::run (this=0xf05960) at
HMSSendHandler.cpp:937
#17 0x00007fddcbba88ec in Thread::_threadFunc (this=0xf05960) at
Thread.cpp:119
#18 0x00007fddcbba8908 in Thread::thread_router (objRun=0xf05960) at
Thread.cpp:133
#19 0x00007fddcc5c23d4 in ?? () from /lib64/libpthread.so.0
#20 0x00007fddc901bc4d in clone () from /lib64/libc.so.6

Could you please help me with , what are the possible causes for abort.

Thanks 
dheeraj

    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

On Wed, Mar 20, 2019 at 1:19 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
> #18 0x00007fddcbba8908 in Thread::thread_router (objRun=0xf05960) at
> Thread.cpp:133

Just to rule something obvious out: did you make sure that libpq
connections are never accessed by multiple threads at the same time?

-- 
Thomas Munro
https://enterprisedb.com

On Wed, Mar 20, 2019 at 02:01:49PM +1300, Thomas Munro wrote:
> Just to rule something obvious out: did you make sure that libpq
> connections are never accessed by multiple threads at the same time?

More to the point: if you do that the memory handling of the internal
libpq structures gets heavily messed up, in ways similar to what your
report shows.
--
Michael