search

CBICA / CaPTk

Cancer Imaging Phenomics Toolkit (CaPTk) is a software platform to perform image analysis and predictive modeling tasks. Documentation: https://cbica.github.io/CaPTk
https://www.cbica.upenn.edu/captk
Other
175 stars 63 forks source link

Perfusion Derivatives crashes in linux version #630

Open chiharusako opened 5 years ago

chiharusako commented 5 years ago

Describe the bug perfusion derivatives crashes on linux

To Reproduce captk PerfusionDerivatives -i $input -e 45 -p 1 -pH 1 -r 1 -o $outdir

Expected behavior output 3 derivatives, ap-RCBV, PH, PSR

CaPTk Version 1.7.2 on cbica cluster

Desktop (please complete the following information):

Additional context

It crashes dumping a core. I also tried submitting as a job with -l h_vmem=64G, and it gave the following error.

Min:0 Max:781.712 Error in `/cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives': malloc(): memory corruption: 0x0000000001d392a0 ======= Backtrace: ========= /usr/lib64/libc.so.6(+0x82e16)[0x7fd36b0f8e16] /usr/lib64/libc.so.6(libc_malloc+0x4c)[0x7fd36b0fb32c] /cbica/software/external/gcc/centos7/4.9.2/lib64/libstdc++.so.6(_Znwm+0x18)[0x7fd36b8ce808] /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives(_ZNSt6vectorIdSaIdEE19_M_emplace_backauxIIRKdEEEvDpOT+0x4b)[0x43bfbb] /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives[0x447f70] /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives[0x448ca0] /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives[0x42bcfc] /usr/lib64/libc.so.6(libc_start_main+0xf5)[0x7fd36b098495] /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives[0x42e4d0] ======= Memory map: ======== 00400000-005dd000 r-xp 00000000 00:29 131504250 /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives 007dd000-007f0000 r--p 001dd000 00:29 131504250 /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives 007f0000-007f1000 rw-p 001f0000 00:29 131504250 /cbica/software/lab/captk/centos7/1.7.2/bin/PerfusionDerivatives 007f1000-007f2000 rw-p 00000000 00:00 0 016b2000-01d60000 rw-p 00000000 00:00 0 [heap] 7fcd74000000-7fcd74021000 rw-p 00000000 00:00 0 7fcd74021000-7fcd78000000 ---p 00000000 00:00 0 7fcd7a439000-7fcfca93c000 rw-p 00000000 00:00 0 7fcfca942000-7fd357c4e000 rw-p 00000000 00:00 0 7fd357c4e000-7fd357c83000 r--s 00000000 fd:00 3664947 /var/db/nscd/passwd 7fd357c83000-7fd357c84000 ---p 00000000 00:00 0 7fd357c84000-7fd35b584000 rwxp 00000000 00:00 0 7fd35b584000-7fd35b5eb000 rw-p 00000000 00:00 0 7fd35b5eb000-7fd35b602000 r-xp 00000000 fd:00 154706 /usr/lib64/libelf-0.172.so 7fd35b602000-7fd35b801000 ---p 00017000 fd:00 154706 /usr/lib64/libelf-0.172.so 7fd35b801000-7fd35b802000 r--p 00016000 fd:00 154706 /usr/lib64/libelf-0.172.so 7fd35b802000-7fd35b803000 rw-p 00017000 fd:00 154706 /usr/lib64/libelf-0.172.so 7fd35b803000-7fd35b807000 r-xp 00000000 fd:00 154871 /usr/lib64/libattr.so.1.1.0 7fd35b807000-7fd35ba06000 ---p 00004000 fd:00 154871 /usr/lib64/libattr.so.1.1.0 7fd35ba06000-7fd35ba07000 r--p 00003000 fd:00 154871 /usr/lib64/libattr.so.1.1.0 7fd35ba07000-7fd35ba08000 rw-p 00004000 fd:00 154871
7ffee47b1000-7ffee47b3000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] .. .. skip .. .. 7fd396aac000-7fd396ace000 rw-p 00000000 00:00 0 7fd396ace000-7fd396acf000 r--p 00021000 fd:00 154145 /usr/lib64/ld-2.17.so 7fd396acf000-7fd396ad0000 rw-p 00022000 fd:00 154145 /usr/lib64/ld-2.17.so 7fd396ad0000-7fd396ad1000 rw-p 00000000 00:00 0 7ffee4775000-7ffee4794000 rwxp 00000000 00:00 0 [stack] 7ffee4794000-7ffee479f000 rw-p 00000000 00:00 0 7ffee47b1000-7ffee47b3000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

sarthakpati commented 5 years ago

This seems to be a memory-related issue. Waiting for @saimarathore to clarify.

sarthakpati commented 5 years ago

@saimarathore is looking into the details with example cases supplied by @chiharusako.

chiharusako commented 4 years ago

I'm following up, and adding that the ones that are crashing are the perfusion images that have 120 timepoints (as opposed to the 45 timepoints we typically had). I'm now using the original-resolution (128x128x19x20, echotime=35ms) perfusion image as the input, so the input file size is about 40MB.

The error is the same as I reported ~below~ earlier. I just tried on 10 images and they all crashed on the same line, independent of how much h_vmem I give to the job.

Thank you