[MonetDB-users] Memory leaks in the latest trunk?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, Recently I decided it was again a good idea(tm) to 'test' the latest MonetDB trunk on an updated dataset. Sadly over the last 6 days I observed a growing memory usage, today resulting in a segmentation fault. For now nothing more than mserver5[26142]: segfault at 8 ip 00007f1e1e592a31 sp 00007f1e00ca63b8 error 4 in libc-2.13.so[7f1e1e515000+17d000] is known to me, which is development wise totally useless. But an other question did arise: is testing currently taking memory into a count? Especially longer tests might show greater usage of memory. It is obviously no problem replay all the queries that ran against the database and valgrind it... but there might have been work done from development respective that can shed light over the problems. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk5OiAAACgkQYH1+F2Rqwn3d+ACdH5ySymgx46EON89qdnlYof39 ZHsAn1LjL9eOHncOjM99+wAupwMC6OR3 =BsVB -----END PGP SIGNATURE-----
Hi Stefan, On 19-08-2011 17:57:52 +0200, Stefan de Konink wrote:
Recently I decided it was again a good idea(tm) to 'test' the latest MonetDB trunk on an updated dataset. Sadly over the last 6 days I observed a growing memory usage, today resulting in a segmentation fault.
For now nothing more than mserver5[26142]: segfault at 8 ip 00007f1e1e592a31 sp 00007f1e00ca63b8 error 4 in libc-2.13.so[7f1e1e515000+17d000] is known to me, which is development wise totally useless. But an other question did arise: is testing currently taking memory into a count? Especially longer tests might show greater usage of memory.
It is obviously no problem replay all the queries that ran against the database and valgrind it... but there might have been work done from development respective that can shed light over the problems.
A lot has happened, so if you can valgrind it, maybe it gives some clues. At the moment both the release and development branches are in bad shape, so you better hold off for a bit.
participants (2)
-
Fabian Groffen -
Stefan de Konink