Running out of client memory triggers an assertion failure which makes the problem (incorrectly) appear to be an internal valgrind error. It should probably just return NULL to the client. An example case is below. Side note: 2.1.1 is the first valgrind version that I've been able to build and run on my gentoo box with only NPTL available (no LinuxThreads compatibility a la RedHat). Thanks! gavin@marquez tmp $ cat oom.c #include <stdlib.h> int main (int argc, char * const argv[]) { int i; void *p; while (1) { p = malloc (131072); if (!p) return 1; } return 0; } gavin@marquez tmp $ gcc -g oom.c -o oom gavin@marquez tmp $ uname -a Linux marquez 2.6.4 #1 Thu Mar 11 09:18:51 CST 2004 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux gavin@marquez tmp $ valgrind --version valgrind-2.1.1 gavin@marquez tmp $ valgrind --tool=memcheck --num-callers=20 ./oom ==1885== Memcheck, a memory error detector for x86-linux. ==1885== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==1885== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==1885== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==1885== For more details, rerun with: -v ==1885== valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. ==1885== at 0xB802FA70: vgPlain_skin_assert_fail (vg_mylibc.c:1211) ==1885== by 0xB802FA6F: assert_fail (vg_mylibc.c:1207) ==1885== by 0xB802FADD: vgPlain_core_assert_fail (vg_mylibc.c:1218) ==1885== by 0xB802BBEF: vgPlain_arena_malloc (vg_malloc2.c:535) ==1885== by 0xB802C741: vgPlain_cli_malloc (vg_malloc2.c:1393) ==1885== by 0xB02644F7: vgSkin_malloc (mac_malloc_wrappers.c:181) ==1885== by 0xB8012097: do_client_request (vg_scheduler.c:2886) ==1885== by 0xB800E3E0: vgPlain_scheduler (vg_scheduler.c:1065) ==1885== by 0xB802A2E2: main (vg_main.c:2994) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==1885== at 0x3C01E40D: malloc (vg_replace_malloc.c:105) ==1885== by 0x804839F: main (oom.c:11) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks.
Created attachment 5390 [details] Patch to give proper error message when allocation fails Try this patch. I think it does the right thing, but I'm not certain; for one, with Memcheck the test program only does about 2200 allocations (about 230MB) before failing. That seems low.
That does make things clearer, thanks. gavin@marquez tmp $ valgrind --tool=memcheck --num-callers=20 ~/tmp/oom ==1049== Memcheck, a memory error detector for x86-linux. ==1049== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==1049== Using valgrind-2.1.2-CVS, a program supervision framework for x86-linux. ==1049== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==1049== For more details, rerun with: -v ==1049== VG_(client_alloc): newSuperBlock's request for 1048576 bytes failed. VG_(client_alloc): 332398592 bytes already allocated. This may mean that you have run out of swap space, since running programs on valgrind increases their memory usage by up to 3 times. You might want to use 'top' to determine whether you really have run out of swap. If so, you may be able to work around it by adding a temporary swap file -- this is easier than finding a new swap partition. Go ask your sysadmin(s) [politely!] VG_(client_alloc): out of memory! Fatal! Bye!
Renamed bug in an attempt to avoid more duplicates.
I think this is a genuine bug, rather than just comment. I was using valgrind-1.9.6 and it was allowing my application to allocate upto 2700 MB. But the recent 2.1.1 version allows for just 620 MB. My test case: cat test.c #include <stdio.h> #include <malloc.h> int main () { int i = 0; for (i = 0; i < 200; i++ ) { printf("%d. ", i); fflush(stdout); malloc ( 20 * 1024 * 1024 ); } } valgrind --skin=addrcheck --alignment=8 ./a.out ==13887== Addrcheck, a fine-grained address checker for x86-linux. ==13887== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==13887== Using valgrind-1.9.6, a program instrumentation system for x86-linux. ==13887== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==13887== Estimated CPU clock rate is 3091 MHz ==13887== For more details, rerun with: -v ==13887== 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. VG_(get_memory_from_mmap): request for 20975616 bytes failed. VG_(get_memory_from_mmap): -1099914329 bytes already allocated. This may mean that you have run out of swap space, since running programs on valgrind increases their memory usage at least 3 times. You might want to use 'top' to determine whether you really have run out of swap. If so, you may be able to work around it by adding a temporary swap file -- this is easier than finding a new swap partition. Go ask your sysadmin(s) [politely!] VG_(get_memory_from_mmap): out of memory! Fatal! Bye! valgrind --skin=addrcheck ./a.out ==12906== Addrcheck, a fine-grained address checker for x86-linux. ==12906== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==12906== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==12906== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==12906== For more details, rerun with: -v ==12906== 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. ==12906== at 0xB802F1B0: vgPlain_skin_assert_fail (vg_mylibc.c:1211) ==12906== by 0xB802F1AF: assert_fail (vg_mylibc.c:1207) ==12906== by 0xB802F21D: vgPlain_core_assert_fail (vg_mylibc.c:1218) ==12906== by 0xB802B323: vgPlain_arena_malloc (vg_malloc2.c:535) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==12906== at 0x7501D8B1: malloc (vg_replace_malloc.c:105) ==12906== by 0x804850D: main (mj.c:9) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks.
If you try the CVS HEAD, things have improved somewhat -- you should be able to allocate quite a lot more memory before running out. The error message hasn't been fixed yet (it's true that malloc() should return 0 if it fails, rather than aborting with an error message), I'm working on it.
Fixed.