you could wrap the executable in a shell script that uses unlimit to
restrict a core size to zero. a hack, but maybe worth it if you are
concerned about the core files.
charles
On Fri, 23 Jun 2000, linda hanigan wrote:
> Thank you between file and gdb I was able to gain enough info
> to talk to
Thank you between file and gdb I was able to gain enough info
to talk to the user. She is using ctrl c to break out if she doesn't
have enough information to finish typing the job. I guess I will have
to add something to my programs to give her a more graceful
exit. At least I can quit worrying th
Did you try the file command? Like this:
file core
It will often tell you what program caused the core dump, on Linux
anyway.
- Bob Glover
> Hi all,
> I have one user that is having alot of core dumps. She usually has her
> computer on all day with one screen logged on the computer she
> is s
On Thu, Jun 22, 2000 at 02:04:08PM -0500, linda hanigan wrote:
> I have one user that is having alot of core dumps. She usually has her
> computer on all day with one screen logged on the computer she
> is sitting at and one screen logged in via telnet to the computer in
> the other room. Is there
I believe that the only way a core dump happens is when the "server"
doesn't recognize or has a problem with something in the program. It has
nothing to do with the person logged in or their computer. Unless the
program is calling for the person to have certian permissions, then that
could be a p
James Youngman wrote:
> > "LG" == LG <[EMAIL PROTECTED]> writes:
>
> LG> Can someone tell me of a way to view core dumps
>
> You want to analyze it rather than view it, I guess. You do it like
> this:-
> $ gdb offending-program core The debugger loads in the
> offend
> "LG" == LG <[EMAIL PROTECTED]> writes:
LG> Can someone tell me of a way to view core dumps
You want to analyze it rather than view it, I guess. You do it like
this:-
$ gdb offending-program core The debugger loads in the
offending program and the coredup and you can
