Valgrind report lost memory in RS_PostgreSQL_exec (RS-PostgreSQL.c:386)

[GoogleCodeExporter]

What steps will reproduce the problem?

While testing the RObsDat package with valgrind on, I get the following report:

==11180== 6,609 bytes in 47 blocks are definitely lost in loss record 5,766 of 
6,672
==11180==    at 0x402CE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==11180==    by 0x995180E: RS_PostgreSQL_exec (RS-PostgreSQL.c:386)
==11180==    by 0x40BAD61: do_dotcall (dotcode.c:582)
==11180==    by 0x40F30D3: Rf_eval (eval.c:635)
==11180==    by 0x40F4B69: do_set (eval.c:1871)
==11180==    by 0x40F2E87: Rf_eval (eval.c:607)
==11180==    by 0x40F4CD6: do_begin (eval.c:1557)
==11180==    by 0x40F2E87: Rf_eval (eval.c:607)
==11180==    by 0x40F522F: do_if (eval.c:1336)
==11180==    by 0x40F2E87: Rf_eval (eval.c:607)
==11180==    by 0x40F4CD6: do_begin (eval.c:1557)
==11180==    by 0x40F2E87: Rf_eval (eval.c:607)


What is the expected output? What do you see instead?

No memory leakage expected

What version of the product are you using? On what operating system?

Current Version of RPostgreSQL on CRAN, R 3.0.1, Ubuntu

Please provide any additional information below.

Original issue reported on code.google.com by reus...@pik-potsdam.de on 20 Aug 2013 at 1:37

[GoogleCodeExporter]

Thank you for the report.

Several leaks detected by valgrind during the standard test were eliminated
in r252.
I would be happy if you could test if the problem persists in the latest in 
subversion.

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 23 Aug 2013 at 6:23

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Much better! I still get the following leak:

==8176== 140 (56 direct, 84 indirect) bytes in 2 blocks are definitely lost in 
loss record 527 of 6,132
==8176==    at 0x402CE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==8176==    by 0x99502FA: RS_postgresql_allocConParams (RS-PostgreSQL.c:160)
==8176==    by 0x99504AD: RS_PostgreSQL_newConnection (RS-PostgreSQL.c:240)
==8176==    by 0x40BAD61: do_dotcall (dotcode.c:582)
==8176==    by 0x40F30D3: Rf_eval (eval.c:635)
==8176==    by 0x40F4B69: do_set (eval.c:1871)
==8176==    by 0x40F2E87: Rf_eval (eval.c:607)
==8176==    by 0x40F4CD6: do_begin (eval.c:1557)
==8176==    by 0x40F2E87: Rf_eval (eval.c:607)
==8176==    by 0x40F622C: Rf_applyClosure (eval.c:1003)
==8176==    by 0x40F2C21: Rf_eval (eval.c:654)
==8176==    by 0x40F5A59: R_execClosure (eval.c:1099)

Thanks!

Original comment by reus...@pik-potsdam.de on 23 Aug 2013 at 9:34

[GoogleCodeExporter]

One more leak was detected and eliminated in r271.  The leak occurred when it 
failed to connect.

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 9 Feb 2014 at 3:02