annotate tests/0017/run-test.sh @ 400:8c7453fb5bd9 api-inversion

Invert audioDB::power_flag / audiodb_power() Here the exciting discovery is that the mmap(), memcpy(), munmap() sequence is in fact not safe. In principle an msync() call should be inserted before unmapping for in-core changes to mmap()ed files to be flushed to disk. In this case we work around the problem entirely, by not mmap()ing anything and doing everything with file descriptors. Amusingly, that's probably not desperately safe either, this time because we have to move the file descriptor position (which is also a shared resource). dup() doesn't save us, as the duplicate file descriptor shares a file position. This applies also to the filling of data_buffer in the query loop, and in fact basically any call to lseek(), which is why I'm not fixing it now. Solution: if you have multiple threads all acting at once on a single database, do one audiodb_open() per thread, for now at least.
author mas01cr
date Thu, 27 Nov 2008 16:22:52 +0000
parents fe4dc39b2dd7
children
rev   line source
mas01cr@252 1 #! /bin/bash
mas01cr@96 2
mas01cr@96 3 . ../test-utils.sh
mas01cr@96 4
mas01cr@96 5 if [ -f testdb ]; then rm -f testdb; fi
mas01cr@96 6
mas01cr@96 7 ${AUDIODB} -d testdb -N
mas01cr@96 8
mas01cr@96 9 # tests that the lack of -l when the query sequence is shorter doesn't
mas01cr@96 10 # segfault.
mas01cr@96 11
mas01cr@96 12 intstring 2 > testfeature
mas01cr@96 13 floatstring 0 1 >> testfeature
mas01cr@96 14 floatstring 1 0 >> testfeature
mas01cr@96 15
mas01cr@96 16 ${AUDIODB} -d testdb -I -f testfeature
mas01cr@96 17
mas01cr@96 18 # sequence queries require L2NORM
mas01cr@96 19 ${AUDIODB} -d testdb -L
mas01cr@96 20
mas01cr@96 21 start_server ${AUDIODB} 10017
mas01cr@96 22
mas01cr@96 23 echo "query point (0.0,0.5)"
mas01cr@96 24 intstring 2 > testquery
mas01cr@96 25 floatstring 0 0.5 >> testquery
mas01cr@96 26
mas01cr@96 27 # FIXME: this actually revealed a horrible failure mode of the server:
mas01cr@96 28 # since we were throwing exceptions from the constructor, the
mas01cr@96 29 # destructor wasn't getting called and so we were retaining 2Gb of
mas01cr@96 30 # address space, leading to immediate out of memory errors for the
mas01cr@96 31 # /second/ call. We fix that by being a bit more careful about our
mas01cr@96 32 # exception handling and cleanup discipline, but how to test...?
mas01cr@96 33
mas01cr@96 34 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery
mas01cr@96 35 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1
mas01cr@96 36
mas01cr@96 37 check_server $!
mas01cr@96 38
mas01cr@96 39 echo "query point (0.5,0.0)"
mas01cr@96 40 intstring 2 > testquery
mas01cr@96 41 floatstring 0.5 0 >> testquery
mas01cr@96 42
mas01cr@96 43 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery
mas01cr@96 44 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1
mas01cr@96 45
mas01cr@96 46 check_server $!
mas01cr@96 47
mas01cr@96 48 # see if the server can actually produce any output at this point
mas01cr@96 49 ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -l 1 -f testquery -n 1 > testoutput
mas01cr@96 50 echo testfeature 0 0 1 > test-expected-output
mas01cr@96 51 cmp testoutput test-expected-output
mas01cr@96 52
mas01cr@96 53 stop_server $!
mas01cr@96 54
mas01cr@96 55 exit 104