New programe crashes

[IkomaAndy]

I had just loaded the code on a new server before the recent change. The old code seemed to be fine. The new codes dies in the following manner:

Handle found. Using 9oud14wz. To change, hit 'C' and wait 5 seconds...[foldtrajlite] FATAL ERROR: [010.000] Could not open/create data file
Hit Return

orcus:[/home/acowell/distribfold] cat error.log

========================[ Apr 14, 2002 1:50 PM ]========================
FATAL ERROR: [010.000] {trajtools.c, line 1925} Could not open/create data file

========================[ Apr 14, 2002 1:51 PM ]========================
FATAL ERROR: [010.000] {trajtools.c, line 1925} Could not open/create data file


I'm not seeing the problem. I'm guessing it's a directory permission somewhere. Could I get a pointer where? This directory, /tmp and /var/tmp all look good.

My system:

[IkomaAndy]

Linux orcus 2.2.16-22 #1 Tue Aug 22 16:49:06 EDT 2000 i686 unknown

It's a Red Hat install, probably older. I'm running the icc Linux dist.

[IronBits]

If you run it as root, does it still do it?

[IkomaAndy]

It does exactly the same thing when I run as root. There are no NFS shares or anything funky on the box. Exact same error message.

[Brian the Fist]

Check the known Bugs section of the web site. If this doesn't help, double check permissions on your /tmp directory, and maybe even clean it out a bit if there's lots of junk there.

[IkomaAndy]

I didn't see anything in Known Bugs that seemed similar. It's not permissions in /tmp (I don't think), /tmp is 1777, as is /var/tmp. Regardless, I get the same thing as root. This box only has one partition, /, and /tmp and everything is on it, so it seems that if it were a permissions issue, running it as root would work.

orcus:[/home/acowell/distribfold] ls -ald /tmp /var/tmp /home /home/acowell /home/acowell/distribfold
drwxr-xr-x 11 root root 4096 Apr 14 11:57 /home
drwxr-xr-x 14 acowell acowell 4096 Apr 14 15:27 /home/acowell
drwxr-xr-x 2 acowell acowell 4096 Apr 14 16:19 /home/acowell/distribfold
drwxrwxrwt 10 root root 4096 Apr 14 16:19 /tmp
drwxrwxrwt 2 root root 4096 May 31 2001 /var/tmp
orcus:[/home/acowell/distribfold] df -k
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 9337356 1417568 7445472 16% /

[Brian the Fist]

Did you change anything recently? When did this error begin, with the update today to the new protein? Is it reproducilble? What is the contents of /etc/issue? Have you tried the non-icc version and does it do the same thing?

[IkomaAndy]

I just installed on this machine this morning. The old one seemed to do fine. This started after I deleted the old directory and reinstalled. The non-icc version dies missing an ncurses lib. It is reproduceable-- it happens every single time I try to run it.

[IkomaAndy]

/etc/issue:
Red Hat Linux release 7.0 (Guinness)
Kernel 2.2.16-22 on an i686

[Brian the Fist]

Hmm, not really sure what else it could be.. does your machine meet the minimum system requirements? Can you tell me if there's any files named *.dbf or *.fpt in the /tmp dir? Do their permissions look normal? As a last resort, can you try another machine?

[Jodie]

Originally posted by IkomaAndy
I just installed on this machine this morning. The old one seemed to do fine. This started after I deleted the old directory and reinstalled. The non-icc version dies missing an ncurses lib. It is reproduceable-- it happens every single time I try to run it.

That's an easy one - upgrade your ncurses libs from rpm.

Or cheat and strings the file and discover there's nothing in there that is referenced that the older ncurses lib doesn't have and just make a symbolic link to the new extended version number that it whines about.

*I* would never do something like that and neither should you.

[IkomaAndy]

Thanks Jodie. Doing that, I was able to make it work.

For the curious, I stuck a strace at http://www.cowell.org/~andy/dist.txt. I think it might be related to this segment below...

open("cbdata", O_RDONLY|O_LARGEFILE) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5215, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
read(3, "# res d(ab) 1;4.5-5.1 5.1-5.6 5."..., 4096) = 4096
read(3, "2480 -0.03961 -0.07040 0.7162"..., 4096) = 1119
read(3, "", 4096) = 0
close(3) = 0
munmap(0x40018000, 4096) = 0
open("C4.log", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/tmp/filecUmtCR.dbf", O_RDWR|O_LARGEFILE) = 3
fcntl(3, 0xd /* F_??? */, 0xbffeec54) = -1 EINVAL (Invalid argument)
close(3) = 0
rmdir("/tmp/filecUmtCR.cdx") = -1 ENOTDIR (Not a directory)
unlink("/tmp/filecUmtCR.cdx") = 0
rmdir("/tmp/filecUmtCR.dbf") = -1 ENOTDIR (Not a directory)
unlink("/tmp/filecUmtCR.dbf") = 0
rmdir("/tmp/filecUmtCR.fpt") = -1 ENOTDIR (Not a directory)
unlink("/tmp/filecUmtCR.fpt") = 0
rmdir("/tmp/file5AEk7X") = -1 ENOTDIR (Not a directory)
unlink("/tmp/file5AEk7X") = 0
open("fold_9oud14wz_0_protein.log", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 3

[Brian the Fist]

So just to be clear then, the gcc version works for you but the Intel icc one does not?

You are correct, the problem is with /tmp/filecUmtCR.* where the fcntl there is called with command 0xd which is an unknown command. That is the database library trying to initialize. hmm. still not sure why though, it might be ineresting to see the same section on the version that IS working and see the difference, if you've got a few minutes to spare.