Hi Abria, I don't think the error is about about your drive space, it is about your RAM memory.
Try to watch with 'ps' command in a loop how much memory your mauve instance takes just before the repeatable crash. Also, consider recompiling mauve and using a different BOOST library version and enable extra debug symbols to be retained in the resulting binary. You could be hitting an internal limits of enforced by your parent shell. Read 'man bash' on you system and make sure you raised your limits: ulimit [-HSTabcdefilmnpqrstuvx [limit]] Provides control over the resources available to the shell and to processes started by it, on systems that allow such con‐ trol. The -H and -S options specify that the hard or soft limit is set for the given resource. A hard limit cannot be increased by a non-root user once it is set; a soft limit may be increased up to the value of the hard limit. If neither -H nor -S is specified, both the soft and hard limits are set. The value of limit can be a number in the unit specified for the resource or one of the special values hard, soft, or unlimited, which stand for the current hard limit, the current soft limit, and no limit, respectively. If limit is omitted, the current value of the soft limit of the resource is printed, unless the -H option is given. When more than one resource is specified, the limit name and unit are printed before the value. Other options are interpreted as follows: -a All current limits are reported -b The maximum socket buffer size -c The maximum size of core files created -d The maximum size of a process's data segment -e The maximum scheduling priority ("nice") -f The maximum size of files written by the shell and its children -i The maximum number of pending signals -l The maximum size that may be locked into memory -m The maximum resident set size (many systems do not honor this limit) -n The maximum number of open file descriptors (most systems do not allow this value to be set) -p The pipe size in 512-byte blocks (this may not be set) -q The maximum number of bytes in POSIX message queues -r The maximum real-time scheduling priority -s The maximum stack size -t The maximum amount of cpu time in seconds -u The maximum number of processes available to a single user -v The maximum amount of virtual memory available to the shell and, on some systems, to its children -x The maximum number of file locks -T The maximum number of threads If limit is given, and the -a option is not used, limit is the new value of the specified resource. If no option is given, then -f is assumed. Values are in 1024-byte increments, except for -t, which is in seconds; -p, which is in units of 512-byte blocks; and -T, -b, -n, and -u, which are unscaled values. The return status is 0 unless an invalid option or argument is supplied, or an error occurs while setting a new limit. $ ulimit -l unlimited $ ulimit -m unlimited $ ulimit -s unlimited Finally, as it seems you did not receive your coredump file, execute also teh following from the parent Bourne shell: $ ulimit -c unlimited This will help you getting a filename called core with crashed instance of mauve. After the crash resolve the core file: $ gdb/home/Analysis_Tools/mauve_snapshot_2015-02-13/linux-x64/progressiveMauve On the gdb commandline '(gdb)' type 3 commands: (gdb) where (gdb) bt full (gdb) quit Martin Abria Magee wrote: > Hi Aaron, > I made sure I had read and write access to the tmp directory. I also made > sure that there was plenty of room (storage). I tried your redirection and > was unsuccessful, I got the same error message. Any other suggestions would > be greatly appreciated. Thanks! > *Abria Magee* > abria2...@sbcglobal.net <mailto:abria2...@sbcglobal.net> > > > : > >> *From:* Aaron Darling <aaron.darl...@uts.edu.au >> <mailto:aaron.darl...@uts.edu.au>> >> *Date:* July 7, 2015 at 8:14:35 PM CDT >> *To:* mauve-users@lists.sourceforge.net >> <mailto:mauve-users@lists.sourceforge.net> >> *Subject:* *Re: [Mauve-users] Linux Error- for StripsubsetLCBs* >> >> Hi Abria, see below... >> >> >> On Tue, 2015-07-07 at 17:00 +0000, Abria Magee wrote: >>> I ran mauve on windows to generate an alignment of about 20 genomes. I >>> used that alignment on the Linux machine to stripSubsetLCBs. I >>> received the following error: >>> Storing raw sequence at /tmp/rawseq7173.000 >>> terminate called after throwing an instance of >>> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::ios_base::failure> >>> >' >>> what(): failed mapping file: Cannot allocate memory >>> Aborted (core dumped) >>> >>> I ran the following command: >>> /home/Analysis_Tools/mauve_snapshot_2015-02-13/linux-x64/progressi >>> veMauve /home/ahaynes/MRPAClonalFrame/stripSubsetLCBs >>> /home/ahaynes/MRPAClonalFrame/MRPA_Alignment_mauve >>> /home/ahaynes/MRPAClonalFrame/MRPA_Alignment_mauve.bbcols core_alignmen >>> t.xmfa 500 >>> >>> >>> Could you help me get this working please? Thanks! ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Mauve-users mailing list Mauve-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mauve-users