Re: 5.1-R: zero byte core file.

On Wed, 2003-08-20 at 22:11, Yogeshwar Shenoy wrote:
> While using 5.1-RELEASE, I find that if my application program seg 
> faults, it produces "programname.core"; but it is 0 bytes.
> I ran the exact same program on another machine that was running 
> 4.4-RELEASE, and I do get a core file that I can use with gdb.
> I'd really appreciate if someone could help me resolve this.
> 
> Additional details: 
> - It is not specific to the application program. I tried a 2 line program:
>     char p[8];
>     memcpy(p, "1234567890123456789012345678901234567890", 40);
>  with same results on 5.1-R(0 byte core file) and 4.4-R(usable core file)
> 
> - "ulimit -a" on the 5.1-R machine gives
>    core file size        (blocks, -c) unlimited
> 
> - Just to be sure I used getrlimit() to find what the limit  for 
> RLIMIT_CORE is in my processes, and it is RLIM_INFINITY.
> 
> - I did the basic checks like write permission on current directory, it 
> looks fine.
> 
> Can someone help me resolve this? 
> 
> Thanks,
> Yogeshwar.
Hi,

Is the core file been dumped to an NFS mount? If so, are you need to be
running rpc.lockd or use the "-L" option for the NFS mount. Otherwise,
you'll get the behaviour you've noticed.

When dumping core, the kernel attempts to get an advisory lock on the
corefile, to reduce the overhead in the pathological case where a large
number of processes simultaneously start dumping core to the same file.

There's a conflict between two default behaviours: rpc.lockd doesn't run
by default (disabled in /etc/defaults/rc.conf), and NFS mounts try to
use the service it provides unless you use the "-L" option. So, by
default, advisory locking (and, by extension, core dumping) doesn't work
on NFS mounts. 

The -stable branch doesn't do client-side NFS locking: It's advisory
locking for NFS mounts "works", but is only visible to the local client.

HTH,
Peter.