Re: Possible unitialised memory in FSX

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> I've got a slightly different stack but it seems to be
> the same problem. Took me a while to trace down
> the root cause. r1573237 should fix it.

I'm still seeing one of the warnings:

$ subversion/svnadmin/svnadmin create repo3 --fs-type fsx
$ rm -rf repo3/db/format
$ printf "1\nlayout sharded 2\n" > repo3/db/format
$ subversion/svn/svn mkdir -mm file://`pwd`/repo3/A

$ valgrind -q --suppressions=/home/pm/vg.supp subversion/svnadmin/.libs/lt-svnadmin pack repo3
==14994== Syscall param write(buf) points to uninitialised byte(s)
==14994== at 0x4A97110: __write_nocancel (syscall-template.S:82)
==14994== by 0x4A6AAF3: apr_file_flush_locked (readwrite.c:317)
==14994== by 0x4A6B10F: setptr (seek.c:25)
==14994== by 0x4A6B2E5: apr_file_seek (seek.c:70)
==14994== by 0x411198F: svn_io_file_seek (io.c:3553)
==14994== by 0x50CCA7A: write_changes_container (pack.c:1490)
==14994== by 0x50CD0A8: write_changes_containers (pack.c:1600)
==14994== by 0x50CDC84: pack_range (pack.c:1862)
==14994== by 0x50CE5C6: pack_log_addressed (pack.c:2040)
==14994== by 0x50CEA23: pack_rev_shard (pack.c:2149)
==14994== by 0x50CEC12: pack_shard (pack.c:2204)
==14994== by 0x50CF1F8: pack_body (pack.c:2333)
==14994== Address 0x69a6a98 is 56 bytes inside a block of size 4,096 alloc'd
==14994== at 0x402C1F0: malloc (vg_replace_malloc.c:291)
==14994== by 0x4A6DEEB: pool_alloc (apr_pools.c:1463)
==14994== by 0x4A6E067: apr_palloc_debug (apr_pools.c:1504)
==14994== by 0x4A69573: apr_file_open (open.c:211)
==14994== by 0x410BB89: file_open (io.c:351)
==14994== by 0x41115BD: svn_io_file_open (io.c:3428)
==14994== by 0x50C95A6: initialize_pack_context (pack.c:261)
==14994== by 0x50CE35C: pack_log_addressed (pack.c:1996)
==14994== by 0x50CEA23: pack_rev_shard (pack.c:2149)
==14994== by 0x50CEC12: pack_shard (pack.c:2204)
==14994== by 0x50CF1F8: pack_body (pack.c:2333)
==14994== by 0x50DA6E8: with_some_lock_file (transaction.c:250)
==14994==
Packing revisions in shard 0...done.

I'm not familiar with the code, but as far as I can tell it's the line:

  data->len += PADDING; /* there a few extra bytes at then of the buffer
                           that we want to keep */

in create_table() which extends the sizeof the stringbuf by 8 bytes to
10 bytes total and nothing ever writes to those extra bytes. The
following patch removes the warning, demonstrating that it those bytes
that are triggering it:

Index: subversion/libsvn_fs_x/string_table.c
===================================================================
--- subversion/libsvn_fs_x/string_table.c (revision 1573320)
+++ subversion/libsvn_fs_x/string_table.c (working copy)
@@ -384,6 +384,9 @@ create_table(string_sub_table_t *target,
     = svn_stringbuf_create_ensure(MAX_DATA_SIZE - source->max_data_size,
                                   scratch_pool);
 
+ svn_stringbuf_appendfill(data, 'x', 10);
+ svn_stringbuf_setempty(data);
+
   /* pack sub-strings */
   target->short_string_count = (apr_size_t)source->short_strings->nelts;
   target->short_strings = apr_palloc(pool, sizeof(*target->short_strings) *

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*