headers
Jing Yu | 13 Feb 2006 18:30
Picon

What AceDB "Error status = 139" means?

Hello,

I got error message "Error status = 139" while loading data into
acedb.  Does anyone know what that means?  

- The error message never appears when I load each data independently into
an empty database, but will appear when load them together or added
more data into a database that with large part of data existing.  

- I've tried ace_4.9f, ace_4.9p, etc.; 
- The systems so far I've tried are:
   1. SunOS baumwolle 5.10 Generic sun4u sparc SUNW,Ultra-4
   2. SunOS algodon 5.8 Generic_108528-21 sun4u sparc SUNW,Ultra-60
   3. Linux ceres 2.2.16-22smp

And they all gave me the same error message.  And my dataset is not very
large yet, much smaller than that of graingenes (8 block*.wrm files of
mine compare to 69 block*.wrm files of graingenes, with the same size of
each block*.wrm in /database).

Can anyone help me on this?  Thank you very much.

Jing
Permalink | Reply | 0 comments |
headers
Jing Yu | 14 Feb 2006 15:45
Picon

Re: What AceDB "Error status = 139" means?

>  have you tried
> loading the data with tace instead of xace?

Yes.  The error message was given from tace.  :(

Jing

On Tue, 14 Feb 2006, Nicolas Thierry-Mieg wrote:

> hello
> 
> this is a long shot, but just in case it's gtk-related: have you tried 
> loading the data with tace instead of xace?
> 
> good luck
> nicolas
> 
> Jing Yu wrote:
> > Hello,
> > 
> > I got error message "Error status = 139" while loading data into
> > acedb.  Does anyone know what that means?  
> > 
> > - The error message never appears when I load each data independently into
> > an empty database, but will appear when load them together or added
> > more data into a database that with large part of data existing.  
> > 
> > - I've tried ace_4.9f, ace_4.9p, etc.; 
> > - The systems so far I've tried are:
> >    1. SunOS baumwolle 5.10 Generic sun4u sparc SUNW,Ultra-4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jing Yu | 14 Feb 2006 17:21
Picon

Re: What AceDB "Error status = 139" means?

> alright, how about stack size limits etc...?
> if you have very large objects I think this could be a problem

That sounds in the right track!  I do have very large objects and that's
where the problem starts to appear ...  I checked the ulimit on my server
(see bellow) but not sure what that means?  what is the current size that
I am having? - Could you give me a hint?  By the way, I run tace under
bash, shall I try other shell?

Thank you.

Jing

=====================
baumwolle:/usr/bin$ more ulimit 
#!/bin/ksh -p
#
#ident  " <at> (#)alias.sh   1.2     00/02/15 SMI"
#
# Copyright (c) 1995 by Sun Microsystems, Inc.
#
cmd=`basename $0`
$cmd "$ <at> "
=====================

On Tue, 14 Feb 2006, Nicolas Thierry-Mieg wrote:

> alright, how about stack size limits etc...?
> if you have very large objects I think this could be a problem
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Matthews | 14 Feb 2006 18:04
Picon

ulimit ["Error status = 139"]

Hi Jing,

> I checked the ulimit on my server
> (see bellow) but not sure what that means?  what is the current size that
> I am having? - Could you give me a hint?

In bash, say "ulimit -a".
On greengenes this gives me:

$ ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) 0
nofiles(descriptors) 64
memory(kbytes) unlimited

This reminds me, a few months ago I had to reset the limit on descriptors
(the number of files open at the same time) in order to load GrainGenes.
User acedb's .cshrc has this:

# dem 8nov05: The default 64 descriptors isn't enough for loading ACEDB now.
unlimit descriptors

This is because GG's database/ directory has so many files, which isn't
your problem.

If your problem is running out of stack space there might be a message in
the system log, /var/adm/messages or wherever it is in baumwolle.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Thierry-Mieg | 16 Feb 2006 17:55
Picon
Picon
Favicon

acediff bug

hi all,

I've run into what looks like a bug in acediff.
This happens with all versions I've tested, ie today's daily build and 
the current supported build, both with dynamically linked binaries. I've 
also tested the current supported static build, same result.
All of this, on linux (FC4, kernel 2.6.14-1.1656_FC4 on a pentium4 system)

Here is a tiny example to illustrate the problem:
$ more wspec/models.wrm
?Interaction Bait UNIQUE ?Text
              Prey UNIQUE ?Text
              fns

$ more test1.ace
Interaction : "test1"
Bait "bait1"
Prey "prey1"

$ more test2.ace
Interaction : "test1"
Bait "bait1"
Prey "prey1"
fns

$ ace.supported/acediff test1.ace test2.ace
reading file 1 - 4 lines read - sorting file 1
reading file 2 - 6 lines read - sorting file 2
performing diff - sorting diff
// acediff difference from test1.ace to test2.ace
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jing Yu | 14 Feb 2006 20:28
Picon

Re: What AceDB "Error status = 139" means?

Nicolas,

No error appears after setting up ulimit -s unlimited, and
everything looks fine.  Thank you very much!!

Jing

On Tue, 14 Feb 2006, Nicolas Thierry-Mieg wrote:

>
> bash is fine
>
> ...
> ulimit -a
> to see your current limits
> 
> then eg to set the stack size to max, type:
> ulimit -s unlimited 
>                
> 
> this will only change the limits for your current shell, hence you
> should call tace from it
> 
> when satisfied you can put the correct ulimit commands in your
> .bash_profile to make the changes affect every new shell
>                
>                
> try setting every value to unlimited, at least the memory related ones
> (except core, which you can set to 0 since you probably don't read core
> dumps anyways)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Thierry-Mieg | 24 Feb 2006 17:20
Picon
Picon
Favicon

Re: acediff bug

following up on the below bug report, here is a quick patch which makes 
all -D lines appear first in the acediff output
The resulting diff file is still more heavy than it should be (ie it can 
say "-D somedata" on one line and later add the same data back in the 
object), but at least this prevents data loss...

On a side note, gcc 4.0 and later doesn't support -fwritable-strings, so 
I had to remove this switch from wmake/LINUX_GTK2_4_DEF to compile 
anything. This seems ok for acediff, but I'm not sure how this would 
affect the rest of the code. Is this OK, or is it necessary to use gcc 3 
to compile acedb?

Nicolas Thierry-Mieg wrote:
> hi all,
> 
> I've run into what looks like a bug in acediff.
> This happens with all versions I've tested, ie today's daily build and 
> the current supported build, both with dynamically linked binaries. I've 
> also tested the current supported static build, same result.
> All of this, on linux (FC4, kernel 2.6.14-1.1656_FC4 on a pentium4 system)
> 
> Here is a tiny example to illustrate the problem:
> $ more wspec/models.wrm
> ?Interaction Bait UNIQUE ?Text
>              Prey UNIQUE ?Text
>              fns
> 
> $ more test1.ace
> Interaction : "test1"
> Bait "bait1"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Thierry-Mieg | 23 Feb 2006 16:31
Picon
Picon
Favicon

Protein subclass

hi all,

I am trying to define a subclass named Protein, but this doesn't work 
with any tested xace versions (current supported or daily)
Is this forbidden? If yes, shouldn't xace/tace complain when it reads 
the models?

Here is a small example to illustrate:

######################################
$ more models.wrm
?Ligand Protein
         Sugar

######################################
$ more subclasses.wrm
Class Prot
Visible
Is_a_subclass_of Ligand
Filter Protein

Class Protein
Visible
Is_a_subclass_of Ligand
Filter Protein

Class Sugar
Visible
Is_a_subclass_of Ligand
Filter Sugar
(Continue reading)

Permalink | Reply | 0 comments |

Gmane