Closed leucinedreams closed 6 years ago
Running simply
daligner ens38.dam mySample.db -v
returns
Building index for ens38
`
Building index for mySample
Kmer count = 13,665,341
Using 0.41Gb of space
Segmentation fault (core dumped)`
swapping the samples as
daligner mySample.db ens38.dam -v
results in it segfaulting before acknowledging the reference dam file:
Building index for mySample
`
Kmer count = 13,665,341
Using 0.41Gb of space
Segmentation fault (core dumped)`
Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with
DBsplit -s100 -x1000 mySample.db
then running with a partition
daligner ens38.dam mySample.1
Sorry I wasn't more help, but glad to hear you figured it out. I'll review the code and put in an overflow check so hopefully the next time it happens to someone they get a friendlier exit :-) My apologies, Gene
On 2/6/18, 5:49 PM, leucinedreams wrote:
Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with
|DBsplit -s100 -x1000 mySample.db|
then running with a partition
|daligner ens38.dam mySample.1|
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/thegenemyers/DALIGNER/issues/76#issuecomment-363487058, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkkNhESHRVmLtreRYtngszKBjHrNzd-ks5tSIKKgaJpZM4R5n3b.
It's a pleasure to play the role of the cautionary tale to future daligner users! Cheers!
I was expecting to find an unguarded request for memory in my code, which would have explained the crash you were getting, instead of an error message. But I checked all my code, and every time I allocate or realloc memory there is a check and an error message printed with an exit if the allocation did not work. So I'm wondering how the crash happened. Could you do me the favor of recompiling daligner with the -g option, running it in gdb (or lldb) and giving me a backtrace (bt command) from where the error occurs? -- Gene
On 2/6/18, 5:49 PM, leucinedreams wrote:
Aaaaahh. The size of the index is excessive, and is likely resulting in overflowing the available memory (though there is no explicit indication that this is what is going on apart from the segmentation fault), as described in the wordpress. The problem is solved by partitioning my sample with
|DBsplit -s100 -x1000 mySample.db|
then running with a partition
|daligner ens38.dam mySample.1|
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/thegenemyers/DALIGNER/issues/76#issuecomment-363487058, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkkNhESHRVmLtreRYtngszKBjHrNzd-ks5tSIKKgaJpZM4R5n3b.
I have a dataset that maps to a reference .dam nicely using damapper, but when I attempt to map with the same file using daligner, either to a reference genome .dam or to itself, it returns zero hits. I've tried to incrementally increase the permissiveness by increasing -w and decreasing -h, but still nothing. Mapping the reference .dam against itself also returns no mappings, though I don't know if that's a good way to test whether my install of daligner is broken.