Segmentation fault (core dumped) #29
Comments
|
Which version of TRUST4 did you use? Can you share the file TRUST_a2468381-bf6c-4f08-911e-ec39c1253add_gdc_realn_rehead_final.out or TRUST_94b39980-23a2-4178-9bec-8b63acbd4c71_gdc_realn_rehead_final.out so I can debug the issue? I feel like the last error could also be related to the annotation issue, since it happens during the stage of rough annotation. Thank you. |
|
Yes. Thank you so much for your fast response! I'm using TRUST4 v1.0.0 TRUST_94b39980-23a2-4178-9bec-8b63acbd4c71_gdc_realn_rehead_final.out.txt |
|
I just tried the two files, and they both work on my system. Could you please pull the newest github repo and give it a try? For test, you can just run the command like: newest_trust4_path/annotator -f newest_trust4_path/human_IMGT+C.fa -a TRUST_94b39980-23a2-4178-9bec-8b63acbd4c71_gdc_realn_rehead_final.out -t 1 -o TRUST_94b39980-23a2-4178-9bec-8b63acbd4c71_gdc_realn_rehead -r TRUST_94b39980-23a2-4178-9bec-8b63acbd4c71_gdc_realn_rehead_assembled_reads.fa > tmp.out to make sure it works without running the whole stages. Please let me know whether it works. |
|
This does indeed work! I will try it again with all my files and will let you know if I run into any more errors |
|
So sorry, but I'm still running into the same Segmentation fault (core dumped) error as before.
I'm now using TRUST4 v1.0.2-beta Here is the final.out: TRUST_24c6110f-257e-49c1-9900-dd36a4d026b9_gdc_realn_rehead_final.out.txt.zip Let me know if you have any other thoughts. Thanks! |
|
I think I just fixed a bug. Could you please pull/clone and recompile TRUST4 to test this sample? You need to rerun it with ./run-trust4, since the bug seems from earlier stages. |
|
I'm so sorry, but I pulled the updated package and recompiled TRUST4, however, I am still running into the same issue: It seems as if the program fails when initial BAM files are too large. From what I've seen, when the .fq files exceed 100 Mb it causes the segmentation fault. Even larger files .fq > 400 Mb do not even reach the final.out stage. Do you think it would be helpful if I tried running TRUST4 in parallel in multiple nodes?
Final.out file: TRUST_24c6110f-257e-49c1-9900-dd36a4d026b9_gdc_realn_rehead_final.out.zip |
|
We have this bam from TCGA on our server in our system, and TRUST4 could process this sample successfully. Here is my log for this sample of the main trust4 stage: [Thu Dec 31 12:01:05 2020] Read in and count kmers for 100000 reads. The message "Found 1907655 reads." is the same as yours, suggesting the fq files are the same. However, the numbers in "Assembled 857189 reads." is slightly different, which means there might be bugs during assembly. I'm currently checking this on a different system. Can you show me the last few lines of the file TRUST_24c6110f-257e-49c1-9900-dd36a4d026b9_gdc_realn_rehead_toassemble_1.fq and do a "wc" on these two fastq files so I can make sure the content is the same between your results and mine? Thank you. |
|
Thank you so much for all your help. I really appreciate it. Here are the last few lines: CCCFFFFFHHGHHJJJJJJJJJJJJJJJJJJJIJJJDGHIJJJJJJJJ And here are the word counts:
|
|
I just tested the sample on a different system and also tried various gcc versions, they all gave the same result. Just want to make sure, when you pull the new version of TRUST4, did you "make clean" first before recompile TRUST4? If this is not the case, can you try it on a different system or allocate more memory if you are using computational platform like slurm? For running on a different system, you can copy the two files toassemble*.fq out, and just run ./trust4 -f ../hg38_bcrtcr.fa -1 XXX_toassemble_1.fq -2 XXX_toassemble_2.fq to see whether the numbers in the log match. Thank you! |
|
Hi, I got the same error as grhogg did. The end of the error message is the same as grhogg posted above (quoted below). Used TRUST4 v1.0.2-beta. The difference is that the trust4 run on majority of the samples (50+) finished successfully. 15% of the runs failed with this error. Let me know if you need further info. Thanks! |
|
Part of the issue is addressed in the newest version (v1.0.2), could you please give it a try? If it still fails at the "annotator" program, could you please share some of the "XXX_final.out" file from the failed samples? Thank you! |
|
Will give it a try. Thanks! |
|
Hi, it still failed in most previously failed samples except one finished successfully. I've attached *_final.out files from two failed samples for you to take a look. Thanks. |
|
Thanks for sharing the data. I just tested it on our system, it works fine and the memory access pattern is also normal. I'm wondering whether this is fixed in the updates in the past week. Could you please try the most updated version on github with "git clonel" and give it a try? Thank you. |
|
I did use the most updated version v1.0.2 for the data above. For memory, 25gb was allocated. Is it enough? Anything else I can look into? Thanks! |
|
Could you please show me all the screen output from TRUST4 for one of the samples? I just checked the length of the assemblies and some of them are quite short, suggesting there might be some very short reads or read through issue for some mate pairs. I fixed a bug regarding such short read length after releasing v1.0.2. Just want to make sure, did you use the version through "git clone" or downloaded v1.0.2 from the release page? Thank you. |
|
It was downloaded from the release page. I've attached a screen output from one sample. |
|
I just tried the v1.0.2 version on the release page, indeed it crashed on your data. I think the new updates have fixed this issue. Could you use "git clone" to get the newest version and give it a try? If this one works, I will create a new release. Thank you. |
|
I tried using 'git clone' but still got the same segmentation error... |
|
Is the log the same as the previous run? I just want to confirm it crashed at the same step. Thank you for your patience. |
|
Yes, log is the same. Failed at the step of annotation assemblies. Thanks. |
|
Could you please share the file for the new 8_TCR_final.out or 16_TCR_final.out again? Those files could be slightly different from the v1.0.2 run. Thank you. |
|
Sure, attached. Thanks. |
|
I'm so puzzled, it still works on my computer. Could you please share the two files, 8.TCR_toassemble_1.fq and 8.TCR_toassemble_2.fq? Thanks for your help on debugging TRUST4. One unlikely reason is the -O3 optimization flag in the Makefile. Can you change it to just "-O", and do a "make clean; make" to recompile TRUST4, and then test it again? |
|
I'm not sure if it's related to my system. But it finished with success on many other samples... I've attached the files you asked for. Thanks for testing them. |
|
It's strange, here is the log of the assembly module in TRUST4 for the v1.0.2 downloaded on the release page: [Wed Mar 3 16:32:16 2021] Read in and count kmers for 100000 reads. By comparing with your log file, the initial reads should be the same, but when in the assembly, there are small discrepancies, such as: I guess there could be something difference on the system or compiler. What is your system and compiler version? I will try to reproduce the issue. In the mean time, since the package on your system is in /share/apps/, can you confirm the program was complied after a "make clean"? Thank you. |
|
@gthunger I just fixed an issue that seems to affect more on the macOS. Could you please "git pull" the new code and give it a try? Thank you. |
|
Hi @grhogg , I think this update could also fix the crash issue on your data. Though it was a few months ago, could you please give it a try if you still need the results? Thank you. |
|
I have a same issue in using TRUST4 SW. I think the bigger bam file seems to be have more error. How can I get some help about this problem? |
|
@arquina Is your TRUST4 version from "git clone" ? Could you please show me the screen output so that we can see which stage it crashed on? Thank you. |
|
Yes! I downloaded the TRUST4 using "git clone" and conduct make clean and make. |
|
@arquina Thank you for providing the information. I think I've found and fixed the bug. Could you please "git pull" the updates and give it a try? Thank you. |
|
Thank you. I update the code and retry to run TRUST4. It seems the error is changed but still have an error. Here is the result of the code. double free or corruption (!prev)
|
|
That is strange. I just tested and checked the memory access pattern again, it looked fine on our server, and I obtained the same numbers as your output. Just want to make sure, have you tried "make clean" before remake TRUST4? Thank you. |
|
Oh! It works! Thank you for your kind answer. I will ask later if I had some issue for running TRUST4. Thank you. |
Hello! Thank you so much for creating this awesome package. I am trying to run TRUST4 on a large set of BAM files; however, I find that for most of the files the function fails and returns various errors (most commonly) "Segmentation fault (core dumped)"
Here is my system call:
For some files, the function works beautifully and completes:
However, for most of the BAM files, TRUST4 fails to complete due to a segmentation fault:
And sometimes it fails due to corrupted unsorted chunks (glibc detected)
and sometimes it fails without any obvious clues as to why:
Any thoughts as to why I may be running into this problem would be greatly appreciated! and Thank you again for creating this awesome function!
The text was updated successfully, but these errors were encountered: