ftp - memory fault (core dump)

[JessieG]

I tried to issue an ftp command from one HP-UX 11i server1 to another HP-UX 11i server2 and got the following error message.

ftp server1
Connected to server1
220 server1 FTP server (Version 1.1.214.4(PHNE_30432) Thu Feb 26 10:46:14 GMT 2004) ready.
Memory fault(coredump)

What could be the cause of the problem? Can anyone help?

[RAC_1]

what does following say??
file core

Are you up to date on patches?? Particularly ftp patches??

Any other errors with system?? Check syslog.log, dmesg

[JessieG]

I have'nt applied any patches yet coz it's been working for a long time without any problem and I just encountered it yesterday.

I'm just wondering how come no new core file has been created.

Here's the output of swlist.

root @ server1 : /var/adm/syslog # swlist -l product | grep -i ftp
PHKL_24278 1.0 Softpower enablement for bladed servers
PHNE_27765 1.0 ftpd(1M) patch

[RAC_1]

Just because it was working does not mean that it should keep working. Some other changes may trigger this. So patching is very important.

Also what about coredump?? Check it in dir from where you started ftp.

Also you did not answer following. Any other error messages??

syslog.log
dmesg

[JessieG]

No error has been logged in dmesg/syslog during ftp.

I found this core file and here's the output of #file core

root @ server1 : / # file /insight1/home/ftp/ftphttl/PROD/data/core/insight1/home/ftp/ftphttl/PROD/data/core: core file from 'ftp' - received SIGSEGV

[Arunvijai_4]

Here is a latest patch to FTP PHNE_33412

http://www1.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHNE_33412&context=hpux:800:11:11

-Arun

[rick jones]

SIGSEGV often means that the program went chasing a bogus pointer. It may have gotten that bogus pointer from a failled malloc() call where it didn't check the return. The malloc() call may have failed for lack of memory or perhaps lack of swap space.

Either way it is indeed a bug in the application, and if the latest patch does not resolve it, should be reported through channels.

For additional debugging points, if the problem happens consistently, you could try tusc'ing the application. The pattern of system calls may help determine just where things go wrong.

[Kent Ostby]

The patch you list is several back so the above ideas to update it are good.

One thing that seems odd is that you listed PHNE_27765 as the FTP patch but then the message above shows PHNE_30432 ... which is a later patch.

Is the patch level different between the two boxes?

This shouldn't be an issue, but you want to make sure that you are updating the machine that had the actual core dump versus the target machine when it comes to patching.