[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AddressSanitizer: global-buffer-overflow message

From: Kristian <kristianonline28_at_gmail.com>
Date: Wed, 6 Jul 2016 18:45:15 +0200

Hey guys,

I have a question. I compiled svn 1.9.4 together with apr, apr-util, serf
and openssl in a Docker container for some testing purposes. I compiled it
with the gcc compiler options for the address sanitizer.

Now, I checkout some source code from my svn repository with Jenkins into
that Docker container. When I go in the shell to that directory and call
"svn info", I get the message:

*****
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/root/trunk/libint'
is too old (format 8) to work with client version '1.9.4 (r1740329)'
(expects format 31). You need to upgrade the working copy first.
*****

Now, I want to make an upgrade, so I call "svn upgrade". But now I am
getting an error message from the AddressSanitizer:

=================================================================
==153== ERROR: AddressSanitizer: global-buffer-overflow on address
0x7f7cddf64369 at pc 0x7f7cddd8ece0 bp 0x7ffc666b4300 sp 0x7ffc666b42f0
READ of size 1 at 0x7f7cddf64369 thread T0
    #0 0x7f7cddd8ecdf in fillInUnixFile
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:27640
    #1 0x7f7cddd90616 in unixOpen
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:28257
    #2 0x7f7cddd75e11 in sqlite3OsOpen
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:15082
    #3 0x7f7cddda69be in sqlite3PagerOpen
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:41802
    #4 0x7f7cdddbfc2e in sqlite3BtreeOpen
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:50150
    #5 0x7f7cdded9d0a in openDatabase
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:114993
    #6 0x7f7cddeda313 in sqlite3_open_v2
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:115129
    #7 0x7f7cddd6ba34 in internal_open
/root/subversion-1.9.4/subversion/libsvn_subr/sqlite.c:911
    #8 0x7f7cddd6c1c0 in svn_sqlite__open
/root/subversion-1.9.4/subversion/libsvn_subr/sqlite.c:1091
    #9 0x7f7cdfab755d in svn_wc__db_util_open_db
/root/subversion-1.9.4/subversion/libsvn_wc/wc_db_util.c:141
    #10 0x7f7cdfa5c14d in create_db
/root/subversion-1.9.4/subversion/libsvn_wc/wc_db.c:1441
    #11 0x7f7cdfa966e6 in svn_wc__db_upgrade_begin
/root/subversion-1.9.4/subversion/libsvn_wc/wc_db.c:13383
    #12 0x7f7cdfa5330e in svn_wc_upgrade
/root/subversion-1.9.4/subversion/libsvn_wc/upgrade.c:2470
    #13 0x7f7cdfe14734 in svn_client_upgrade
/root/subversion-1.9.4/subversion/libsvn_client/upgrade.c:114
    #14 0x45202c in svn_cl__upgrade
/root/subversion-1.9.4/subversion/svn/upgrade-cmd.c:73
    #15 0x44f75c in sub_main
/root/subversion-1.9.4/subversion/svn/svn.c:3041
    #16 0x44fc8d in main /root/subversion-1.9.4/subversion/svn/svn.c:3126
    #17 0x7f7cdc6eeb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
    #18 0x406dc8 in _start (/usr/local/bin/svn+0x406dc8)
0x7f7cddf64369 is located 55 bytes to the left of global variable '*.LC1094
(subversion/libsvn_subr/sqlite3wrapper.c)' (0x7f7cddf643a0) of size 10
  '*.LC1094 (subversion/libsvn_subr/sqlite3wrapper.c)' is ascii string
'unix-none'
0x7f7cddf64369 is located 4 bytes to the right of global variable '*.LC1093
(subversion/libsvn_subr/sqlite3wrapper.c)' (0x7f7cddf64360) of size 5
  '*.LC1093 (subversion/libsvn_subr/sqlite3wrapper.c)' is ascii string
'unix'
SUMMARY: AddressSanitizer: global-buffer-overflow
/root/subversion-1.9.4/sqlite-amalgamation/sqlite3.c:27640 fillInUnixFile
Shadow bytes around the buggy address:
  0x0ff01bbe4810: 07 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9
  0x0ff01bbe4820: 00 01 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
  0x0ff01bbe4830: 05 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x0ff01bbe4840: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
  0x0ff01bbe4850: 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 07
=>0x0ff01bbe4860: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 05[f9]f9 f9
  0x0ff01bbe4870: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 05 f9 f9
  0x0ff01bbe4880: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 01 f9 f9 f9
  0x0ff01bbe4890: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x0ff01bbe48a0: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 01 f9 f9
  0x0ff01bbe48b0: f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable: 00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone: fa
  Heap righ redzone: fb
  Freed Heap region: fd
  Stack left redzone: f1
  Stack mid redzone: f2
  Stack right redzone: f3
  Stack partial redzone: f4
  Stack after return: f5
  Stack use after scope: f8
  Global redzone: f9
  Global init order: f6
  Poisoned by user: f7
  ASan internal: fe
==153== ABORTING

Is this a problem of svn or sqlite?
Is this already known?

If you need some more information, I will give it to you...
Received on 2016-07-06 18:45:23 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.