This is a lot of the conclusion you have. You should have concentrated it more on areas of interest to you. However, I will try to give some general pointers.
==2441== Invalid write of size 4
opens a "block" that tells you detailed information about the allocated memory and the back trace of the stack of its placement and the error site. ==2441== is the PID of the process, which is useful in cases where several processes are running in parallel.
Website errors (comments added with # ). The stack path is always in the reverse order, which means crash (or something that could become a crash in normal mode). The site is at the top of the list, and the calls it invokes are listed in reverse order below:
# This points to a function nodes_term32_flush() in file tyn_indexer.c on line 227 ==2441== at 0x404893: nodes_term32_flush (tyn_indexer.c:227) # the format is the same, at this line tyn_exsorter_sort() calls nodes_term32_flush() ==2441== by 0x407B77: tyn_exsorter_sort (tyn_exsorter.c:131) # ... and so on ==2441== by 0x406DDE: tyn_build_index (tyn_indexer.c:731) # ... leading up to the process "entry point" ==2441== by 0x40384F: main (tyn_indexer.c:943)
The memory block is damaged. The first line tells us that a block from one MiB was allocated and that (together with the output above) you read the first 4 bytes (probably a 32-bit value) after the last allocated byte of this block. The rest of the format matches what you know from the stack above.
==2441== Address 0x1233c080 is 0 bytes after a block of size 1,048,576 alloc'd ==2441== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==2441== by 0x406BEB: tyn_build_index (tyn_indexer.c:663) ==2441== by 0x40384F: main (tyn_indexer.c:943)
All repetitions after this - from experience - are most often the result of the first mistake. Thus, it always starts to fix the first indicated problem in the sequence of problem reports.
Now for the other error class that appears in your release:
==2441== Use of uninitialised value of size 8 # All library functions here ... ==2441== at 0x3AE9C4726B: _itoa_word (in /lib64/libc-2.14.90.so) ==2441== by 0x3AE9C49852: vfprintf (in /lib64/libc-2.14.90.so) ==2441== by 0x3AE9C51FE8: printf (in /lib64/libc-2.14.90.so) # ... but this one should be yours. Check out this file/line to see what can be the problem with the printf() call ==2441== by 0x4071EF: tyn_build_index (tyn_indexer.c:888) ==2441== by 0x40384F: main (tyn_indexer.c:943)
The following, most likely, is again a consequence of the above conclusion:
==2441== Conditional jump or move depends on uninitialised value(s) ==2441== at 0x3AE9C47275: _itoa_word (in /lib64/libc-2.14.90.so) ==2441== by 0x3AE9C49852: vfprintf (in /lib64/libc-2.14.90.so) ==2441== by 0x3AE9C51FE8: printf (in /lib64/libc-2.14.90.so) ==2441== by 0x4071EF: tyn_build_index (tyn_indexer.c:888) ==2441== by 0x40384F: main (tyn_indexer.c:943)
I highly recommend two things: read the Valgrind manual (I know it sounds to patronize, but it's worth it) and use its many options. I created several functions that I use on my development machines:
vgrun just runs the command with Valgrind. Note that the command must be in quotation marks with all its parameters for this. vgtrace is simply a variation of vgrun , adding --trace-children=yes to the Valgrind command line. The most useful, by far, is vgdbg , which will ask you to connect GDB to the running program and, thus, will allow you to interactively debug the problem, including correctly checking the stack frames, values, etc. - if you say GDB, that is.