writeBloom.pl

[elor77]

Hi, After much trouble succeeded compiling bloomfilter using g++4.8. Now when running either through links or through tools I get the following error:

Attempt to free unreferenced scalar: SV 0x55eef06034f8, Perl interpreter: 0x55eef05e2010 at /local/workdir/eoren/links_v1.8.6/tools/../lib/bloomfilter/swig/BloomFilter.pm line 118. Wed Jan 2 11:48:23 EST 2019:Shredding supplied sequence file (-f ../../melon/assembly/dul/input/ONT/dul2.short.fastq) into 21-mers.. Contigs processed k=21: 1

Something went wrong running writeBloom.pl Wed Jan  2 11:50:10 EST 2019'
RuntimeError Usage: insertSeq(bloom,seq,numHashes,k); at writeBloom.pl line 184, <IN> line 5278940.

[lcoombe]

Hi @elor77 , Have you checked your bloom filter compilation using the test.pl script?

[lcoombe@gphost05 swig]$ ./test.pl 
de novo bf tests done 
Storing filter. Filter is 125000000bytes.
Loading header...
premade bf tests done
Filter Info: Pop - 20, numHash - 5, kmerSize - 20, size - 1000000000
0 TAGAA found
1 AGAAT found
2 GAATC found
3 AATCA found
4 ATCAC found
5 TCACC found
6 CACCC found
7 ACCCA found
8 CCCAA found
9 CCAAA found
10 CAAAG found
11 AAAGA found
Done!

[elor77]

Hi @lcoombe , I get a similar error:

Attempt to free unreferenced scalar: SV 0x153b510, Perl interpreter: 0x151a010 at /local/workdir/eoren/links_v1.8.6/lib/bloomfilter/swig/./BloomFilter.pm line 118.
No matching function for overloaded 'BloomFilter_insert' at ./test.pl line 13.

[lcoombe]

Have you taken a look at #21? Looks like another user had a similar issue that was solved by increasing the memory available.

[elor77]

I've looked at it - it does look similar,

increasing memory available in the scheduler did the trick

Unfortunately, I'm not a programmer and after googling it, I haven't come up with any clear examples how to do that. My machine has 512Gb of RAM but if I understand correctly it has to do with allocated memory for the process..

[lcoombe]

@elor77 - Is the machine being heavily used by any other users? You can check how much memory is available with free. If you are running the jobs directly on that machine (ie. not using a job scheduler like slurm), and there is plenty of memory I'd be surprised if memory was the issue.

I can't reproduce the error unfortunately - I re-compiled the module using g++ 4.8.3 and perl 5.28.0 (LINKS v1.8.6), and the tests ran without any issue. If you'd like me to look at the steps you used to compile the module, feel free to post them here.

[elor77]

Thank you! Warm regards,

Elad Oren, Ph.D student Newe-Ya'ar Research Center, Agricultural Research Organization, Ministry of Agriculture P.O. Box 1021, Ramat Yishay 30095 Israel

Mobile +972 (0)54 9846321 Tel +972 (0)04 9539553 Fax +972 (0)77 4703457

On Thu, Jan 3, 2019 at 2:30 AM lcoombe notifications@github.com wrote:

@elor77 https://github.com/elor77 - Is the machine being heavily used by any other users? You can check how much memory is available with free. If you are running the jobs directly on that machine (ie. not using a job scheduler like slurm), and there is plenty of memory I'd be surprised if memory was the issue.

I can't reproduce the error unfortunately - I re-compiled the module using g++ 4.8.3 and perl 5.28.0 (LINKS v1.8.6), and the tests ran without any issue. If you'd like me to look at the steps you used to compile the module, feel free to post them here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bcgsc/LINKS/issues/33#issuecomment-451027370, or mute the thread https://github.com/notifications/unsubscribe-auth/Aq0fhS8o5gxkXWyLLNIF00wi5diXwrLsks5u_U8ZgaJpZM4Zm7uS .