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*
> [email protected] <mailto:[email protected]>
>
>
> :
>
>> *From:* Aaron Darling <[email protected]
>> <mailto:[email protected]>>
>> *Date:* July 7, 2015 at 8:14:35 PM CDT
>> *To:* [email protected]
>> <mailto:[email protected]>
>> *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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mauve-users
