Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@yahoo.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: fio@vger.kernel.org
Subject: Re: Mutex destruction, invalid memory accesses, leaks
Date: Sun, 9 Feb 2014 19:50:42 +0000	[thread overview]
Message-ID: <20140209195042.GA17058@sucs.org> (raw)
In-Reply-To: <52F505A8.30004@kernel.dk>

On Fri, Feb 07, 2014 at 09:11:20AM -0700, Jens Axboe wrote:
> On 2014-02-06 20:44, Sitsofe Wheeler wrote:
> >On Thu, Feb 06, 2014 at 12:21:35PM -0700, Jens Axboe wrote:
> >>
> >>./fio.exe --debug=all --filename=fiojob --thread --size=512 --rw=read --bs=512 --ioengine=sync --verify_pattern=0xdeadbeef --name=fiojobname
> >>
> >>The problem appears to be that the mutex is being destroyed while it
> >>is still being held by a different thread. Adding return; to the first
> >>line of fio_mutex_remove in mutex.c papers over the problem...
> >
> Does this still happen in current -git? The bug is a weird one - it
> looks like it's crashing in bringing up the thread, but the
> synchronization around that should ensure that it never gets to
> touch td->mutex. If the mutexes are broken somehow and the thread
> doesn't properly wait for the main thread to bring it up, then I can
> see it happening. Hence my question whether it's still happening
> after Bruce fixed the pthread linkage in current -git.

Yes it's still happening with -git from a moment ago. What is stopping a
sleeping thread from holding a mutex that is destroyed and then waking
up on it after the memory has been unmapped?

> >Additionally Dr Memory is also flagging up an invalid memory access on
> >the Windows version of fio (one is in a macro which makes a for loop but
> >I only have a non-macro fix for it at the moment) and some memory leaks
> >around string_to_cpu and init_io_u.
> 
> I'm going to need more info on the invalid mem access. Not surprised
> there are a few leaks around the init functions. Would be nice to
> get fixed up, but not a ship-stopper.

Here's the Dr Memory output:
Error #1: UNADDRESSABLE ACCESS: reading 2 byte(s)
# 0 __get_mult_bytes.constprop.5               [fio/parse.c:168]
# 1 str_to_decimal                             [fio/parse.c:237]
# 2 __handle_option                            [fio/parse.c:285]
# 3 handle_option                              [fio/parse.c:861]
# 4 fill_default_options                       [fio/parse.c:1174]
# 5 main                                       [fio/fio.c:40]
Note: refers to 0 byte(s) beyond last valid byte in prior malloc

Error #2: LEAK 11 bytes 
# 0 replace_malloc                     [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 msvcrt.dll!_strdup   
# 2 __handle_option                    [fio/parse.c:615]
# 3 handle_option                      [fio/parse.c:861]
# 4 fill_default_options               [fio/parse.c:1174]
# 5 main                               [fio/fio.c:40]

Error #3: LEAK 26 bytes 
# 0 replace_malloc               [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 msvcrt.dll!_strdup   
# 2 fio_test_cconv               [fio/cconv.c:10]
# 3 main                         [fio/fio.c:40]

Error #4: LEAK 11 bytes 
# 0 replace_malloc               [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 msvcrt.dll!_strdup   
# 2 fio_test_cconv               [fio/cconv.c:10]
# 3 main                         [fio/fio.c:40]

Error #5: POSSIBLE LEAK 35 bytes 
# 0 replace_malloc                                     [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 emutls_alloc                                       [/usr/src/debug/mingw64-i686-gcc-4.8.2-2/libgcc/emutls.c:110]
# 2 __fio_gettime                                      [fio/gettime.c:165]
# 3 _fu0___set_invalid_parameter_handler               [/usr/src/debug/mingw64-i686-runtime-3.1.0-1/crt/crtexe.c:332]
# 4 KERNEL32.dll!BaseThreadInitThunk

Error #6: LEAK 136 bytes 
# 0 replace_calloc                       [d:\drmemory_package\common\alloc_replace.c:2310]
# 1 __emutls_get_address                 [/usr/src/debug/mingw64-i686-gcc-4.8.2-2/libgcc/emutls.c:159]
# 2 __fio_gettime                        [fio/gettime.c:165]
# 3 pthread_create_wrapper               [/usr/src/debug/mingw64-i686-winpthreads-3.1.0-1/src/thread.c:1381]
# 4 msvcrt.dll!_endthreadex
# 5 msvcrt.dll!_endthreadex
# 6 KERNEL32.dll!BaseThreadInitThunk

Error #7: POSSIBLE LEAK 35 bytes 
# 0 replace_malloc                       [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 emutls_alloc                         [/usr/src/debug/mingw64-i686-gcc-4.8.2-2/libgcc/emutls.c:110]
# 2 __fio_gettime                        [fio/gettime.c:165]
# 3 pthread_create_wrapper               [/usr/src/debug/mingw64-i686-winpthreads-3.1.0-1/src/thread.c:1381]
# 4 msvcrt.dll!_endthreadex
# 5 msvcrt.dll!_endthreadex
# 6 KERNEL32.dll!BaseThreadInitThunk

===========================================================================
FINAL SUMMARY:

DUPLICATE ERROR COUNTS:
	Error #   1:     32

-- 
Sitsofe | http://sucs.org/~sits/


  reply	other threads:[~2014-02-09 19:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 19:21 Fio 2.1.5 release upcoming Jens Axboe
2014-02-07  3:44 ` Mutex destruction, invalid memory accesses, leaks Sitsofe Wheeler
2014-02-07 16:11   ` Jens Axboe
2014-02-09 19:50     ` Sitsofe Wheeler [this message]
2014-02-09 20:49       ` Jens Axboe
2014-02-10  9:55         ` Sitsofe Wheeler
2014-02-10 19:25       ` Bruce Cran
2014-02-10 20:22         ` Sitsofe Wheeler
2014-02-10 20:48           ` Jens Axboe
2014-02-10 20:56           ` Jens Axboe
2014-02-11  0:12             ` Elliott, Robert (Server Storage)
2014-02-11  7:07               ` Sitsofe Wheeler
2014-02-11 15:30                 ` Elliott, Robert (Server Storage)
2014-02-11 15:38                   ` Jens Axboe
2014-02-11 22:51                     ` Sitsofe Wheeler
2014-02-12  6:32                       ` Sitsofe Wheeler
2014-02-08 19:52 ` Fio 2.1.5 release upcoming Matthew Eaton
2014-02-09 20:57   ` Jens Axboe
2014-02-10  0:26     ` Matthew Eaton
2014-02-10 22:14       ` Jens Axboe
2014-02-10 23:11         ` Matthew Eaton
2014-02-10 23:15           ` Jens Axboe
2014-02-11  0:00             ` Matthew Eaton
2014-02-11 15:09               ` Jens Axboe
2014-02-11 15:27               ` Jens Axboe
2014-02-11 19:18                 ` Matthew Eaton
2014-02-11 19:29                   ` Jens Axboe
2014-02-11 20:52                     ` Matthew Eaton
2014-02-11 21:21                       ` Jens Axboe
2014-02-11 21:38                         ` Matthew Eaton
2014-02-11 21:42                           ` Jens Axboe
2014-02-12  0:01                             ` Matthew Eaton
2014-02-12  1:46                               ` Jens Axboe
2014-02-12  2:30                                 ` Matthew Eaton
2014-02-11 11:22 ` Paul Alcorn
2014-02-11 15:39   ` 'Jens Axboe'

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140209195042.GA17058@sucs.org \
    --to=sitsofe@yahoo.com \
    --cc=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox