Hi Nate,
We tried a BWA run this morning and this time it gave an error rather
than a crash. Below is just the python error output, I can give a
sanitised full output if you prefer.
However, I can't do any more testing for the time being as the hardware
on our development server has gone to the Great Cluster in the Sky RIP.
We do have a replacement which will be in place soon.
In the meantime, any help appreciated.
Chris
Server Error
URL:
http://wsdev.compbio.dundee.ac.uk:3216/datasets/ec351b7f7460a3bb/display?...
Module paste.exceptions.errormiddleware:143 in __call__
<< try:
__traceback_supplement__ = Supplement, self, environ
app_iter = self.application(environ, start_response)
return self.make_catching_iter(app_iter, environ)
except:>> app_iter = self.application(environ, start_response)
Module paste.debug.prints:97 in __call__
<< threadedprint.register(replacement_stdout)
try:
status, headers, body = wsgilib.intercept_output(
environ, self.app)
if status is None:>> status, headers, body =
wsgilib.intercept_output(
Module paste.wsgilib:552 in intercept_output
<< if len(data) < 2:
data.append(None)
data.append(output.getvalue())
return data>> data.append(output.getvalue())
MemoryError:
extra data
Hi Chris,
Are you using 'run.sh --daemon' or just 'run.sh' (and
daemonizing/backgrounding through some other method, like 'screen')? I'm
asking because it's odd that there's no traceback or even something like
a segfault (which would only be seen if run in the foreground).
If you're starting with --daemon, could you start in the foreground,
cause the crash, and see if anything is output when it happens?
Thanks,
--nate
> Thanks,
>
> Chris
>
> On 05/01/10 11:18, Chris Cole wrote:
>> Hi Kelly,
>>
>> Just getting back to this following the holidays.
>>
>> On 22/12/09 21:32, Kelly Vincent wrote:
>>> Hi Chris,
>>>
>>> Can you confirm that you have a recent changeset (today we're at
>>> 3192:828d9f9dcb29)?
>>
>> 'hg tip' returns 3137:ddd9d5ac0457
>>
>>> If you're using an earlier version, either update or
>>> check that <Galaxy root>/lib/galaxy/datatypes/registry.py contains the
>>> following line:
>>> 'sam' : 'text/plain',
>>> (it should be line 164, as part of the self.mimetypes_by_extension
>>> dictionary definition).
>>
>> Yup, it's there
>>
>>> In either case, make sure the line:
>>> <datatype extension="sam"
type="galaxy.datatypes.tabular:Sam"
>>> display_in_upload="true"/>
>>> appears in <Galaxy root>/datatypes_conf.xml. It should be around line
>>> 51, inside the tag:
>>> <registration
converters_path="lib/galaxy/datatypes/converters">
>>
>> Nope. Not in there.
>>
>> I've added it and it works for small files, but not large ones. Small is
>> 119 lines and large 20 million lines. There are no errors in paster.log,
>> now. Galaxy simply falls over.
>>
>> Would an update solve it?
>> Thanks for your help,
>>
>> Chris
>>
>>> Let us know what you find.
>>>
>>> Regards,
>>> Kelly
>>>
>>>
>>> On Dec 18, 2009, at 11:35 AM, Chris Cole wrote:
>>>
>>>> Hi,
>>>>
>>>> On our local install, we've just enabled bowtie NGS mapping and
>>>> although the search runs fine and the output is viewable in Galaxy,
>>>> any attempt to save it brings down the server.
>>>>
>>>> The only error in paster.log is:
>>>> galaxy.datatypes.registry WARNING 2009-12-18 16:32:38,517 unknown
>>>> mimetype in data factory sam
>>>>
>>>> Tried it on large files and small files with the same effect.
>>>>
>>>> Trying save as fails with an 'unable to read file error'. Anyone
have
>>>> any ideas?
>>>> Cheers,
>>>>
>>>> Chris