Bug:

[JohnUrban]

Hello! It has been quite a while since I've lurked around the MACS github page. Thanks for continuing to maintain MACS. I would like to bring this bug to your attention. It is possible you already know about it, and have a solution.

Describe the bug
This bug arises on my system (uname -a = Linux basecaller.ciwemb.edu 3.13.0-73-generic #116-Ubuntu SMP Fri Dec 4 15:31:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) with MACS3 (macs3 3.0.0a6) installed via pip (pip install macs3 --force-reinstall).

The bug arises with macs3 callpeak only when I try to include a control (-c control.bam). It runs fine with no control.

ValueError: cannot resize this array: it does not own its data
Exception ignored in: 'MACS3.Signal.CallPeakUnit.clean_up_ndarray'
Traceback (most recent call last):
  File "/mnt/sequence/jurban/software/conda/anaconda3/lib/python3.8/site-packages/MACS3/Commands/callpeak_cmd.py", line 249, in run
    peakdetect.call_peaks()
ValueError: cannot resize this array: it does not own its data
ValueError: cannot resize this array: it does not own its data
Exception ignored in: 'MACS3.Signal.CallPeakUnit.clean_up_ndarray'
Traceback (most recent call last):
  File "/mnt/sequence/jurban/software/conda/anaconda3/lib/python3.8/site-packages/MACS3/Commands/callpeak_cmd.py", line 249, in run
    peakdetect.call_peaks()
ValueError: cannot resize this array: it does not own its data
ValueError: cannot resize this array: it does not own its data
Exception ignored in: 'MACS3.Signal.CallPeakUnit.clean_up_ndarray'
Traceback (most recent call last):
  File "/mnt/sequence/jurban/software/conda/anaconda3/lib/python3.8/site-packages/MACS3/Commands/callpeak_cmd.py", line 249, in run
    peakdetect.call_peaks()
ValueError: cannot resize this array: it does not own its data

To Reproduce
All of the following commands produced the error:

macs3 callpeak -t ${BAM} -c ${CONTROL} -g ${GSIZE} --nomodel --extsize ${EXT} --keep-dup all --outdir ${DIR5} -n ${BASE} --bdg --SPMR -q 0.01 --seed ${RSEED} --call-summits 2> ${DIR5}/${BASE}.macs3.err &

macs3 callpeak -t ${BAM} -c ${CONTROL} -g ${GSIZE} --nomodel --extsize ${EXT} --keep-dup all --outdir ${DIR6} -n ${BASE} --bdg --SPMR -q 0.01 --seed ${RSEED} 2> ${DIR6}/${BASE}.macs3.err &

macs3 callpeak -t ${BAM} -c ${CONTROL} -g ${GSIZE} --nomodel --extsize ${EXT} --keep-dup auto --outdir ${DIR7} -n ${BASE} --bdg --SPMR -q 0.001 --seed ${RSEED} 2> ${DIR7}/${BASE}.macs3.err &

macs3 callpeak -t ${BAM} -c ${CONTROL} -g ${GSIZE} --nomodel --extsize ${EXT} --keep-dup 1 --outdir ${DIR8} -n ${BASE} --bdg --SPMR -q 0.001 --seed ${RSEED} 2> ${DIR8}/${BASE}.macs3.err &

Simply removing -c ${CONTROL} from those commands allows MACS to finish just fine.

Expected behavior
A clear and concise description of what you expected to happen:

• expectation = finish without throwing an error haha.

System (please complete the following information):

• OS: Linux
• Python version: 3.8.5
• Numpy version: 1.21.2
• MACS Version: macs3 3.0.0a6
• uname -a = Linux basecaller.ciwemb.edu 3.13.0-73-generic #116-Ubuntu SMP Fri Dec 4 15:31:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Many thanks for any advice.

[JohnUrban]

I can see that #122 and #146 also refer to an error like this. I will read more at #122.

[JohnUrban]

I saw something about trouble writing to /tmp. This could easily be the issue since I had another issue earlier today that I tracked down to a potential space issue in /tmp.

[JohnUrban]

Well - here is an edit to the problem. Now the issue is arising when not using a control as well. So the control had nothing to do with it specifically -- it probably just threw the errors more easily since there was more resources needed. . . . .

[JohnUrban]

I can confirm that the /tmp dir was low on space and that --tempdir localtmpdir solved my problem. Closing issue. :)