[Debian-med-packaging] Bug#933505: bamtools - ppc64el -run-unit-test hangs

Andreas Tille andreas at an3as.eu
Wed Jul 31 14:29:09 BST 2019


Hi Roger,

On Wed, Jul 31, 2019 at 12:55:23PM +0200, Roger wrote:
> I have investigated more - the failing test is
> bamtools filter -script tests/filter_script -in sam_spec_example.bam
> -out out.bam

Thanks a lot for your investigation.  Do you think its a sensible
idea to add some

   if [ $(dpkg-architecture -qDEB_HOST_ARCH) != "ppc64el" ] ; then
       bamtools filter -script tests/filter_script -in sam_spec_example.bam -out out.bam
   fi

around the test as some temporary means?
 
> all other tests pass.
> 
> #----------------------------------------------------------------------------
> which traced gives
> execve("/usr/bin/bamtools", ["bamtools", "filter", "-script",
> "tests/filter_script", "-in", "sam_spec_example.bam", "-out",
> "out.bam"], 0x7fffd265a250 /* 14 vars */) = 0
> fstat(3, {st_mode=S_IFREG|0644, st_size=198896, ...}) = 0
> mmap(NULL, 262552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0x7fff97cd0000
> mmap(0x7fff97d00000, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x20000) = 0x7fff97d00000
> close(3)                                = 0
> mprotect(0x7fff97f20000, 65536, PROT_READ) = 0
> mprotect(0x7fff97d00000, 65536, PROT_READ) = 0
> mprotect(0x7fff97f60000, 65536, PROT_READ) = 0
> mprotect(0x7fff980a0000, 65536, PROT_READ) = 0
> mprotect(0x7fff98320000, 65536, PROT_READ) = 0
> mprotect(0x7fff983e0000, 65536, PROT_READ) = 0
> mprotect(0x7fff98440000, 65536, PROT_READ) = 0
> mprotect(0x12ce50000, 65536, PROT_READ) = 0
> mprotect(0x7fff984f0000, 65536, PROT_READ) = 0
> munmap(0x7fff98460000, 215211)          = 0
> brk(NULL)                               = 0x1001ccb0000
> brk(0x1001cce0000)                      = 0x1001cce0000
> openat(AT_FDCWD, "tests/filter_script", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=352, ...}) = 0
> read(3, "{\n  \"filters\" : \n    [\n      { \""..., 4096) = 352
> read(3, "", 4096)                       = 0
> read(3, "", 4096)                       = 0
> read(3, "", 4096)                       = 0
> read(3, "", 4096)                       = 0
> read(3, "", 4096)                       = 0
> read(3, "", 4096)                       = 0
> 
> ... and that forever
> I have changed the filter_script to add more lines of data, and trace
> shows like at the end of file it doesn't get EOF and try to read more -
> don't understand why !
> 
> openat(AT_FDCWD, "/tmp/filter_script", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=63521, ...}) = 0
> read(3, "{\n  \"filters\" : \n    [\n      { \""..., 4096) = 4096
> read(3, "         }\n{                    "..., 4096) = 4096
> read(3, "                                "..., 4096) = 4096
> brk(0x100387e0000)                      = 0x100387e0000
> read(3, "                                "..., 4096) = 4096
> read(3, "                                "..., 4096) = 4096
> read(3, "                                "..., 4096) = 2081
> read(3, "", 4096)                       = 0

I can forward this investigation to upstream if you have no better clue.
Your result looks in any case suspicious not only for ppc64el.

Kind regards

       Andreas.

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list