Very Computer

by **David McReynold** » Fri, 10 Apr 1998 04:00:00

How can I get the operating system to provide a full core for the
following program?

int main()
{
long i = 0;
char * p = 0;
long a[1000000];
char *cp;
cp = (char*)malloc(1000000);
for(i = 1; i < 1000000; i++)
{
a[i] = i;
*cp = 0x41;
}
*p = 1;
return 0;

Quote:}

The core file is always 26k even though I touched both the array and the
char*.

by **R!ch Tee** » Fri, 10 Apr 1998 04:00:00

> How can I get the operating system to provide a full core for the
> following program?

> int main()
> {
> long i = 0;
> char * p = 0;
> long a[1000000];
> char *cp;
> cp = (char*)malloc(1000000);
> for(i = 1; i < 1000000; i++)
> {
> a[i] = i;
> *cp = 0x41;
> }
> *p = 1;

Dunno off the top of my head, but I'd be inclined not to
try dereferencing a NULL pointer (thereby avoiding the
segmentation violation in the first place). I don't
understand the logic involving your use of "p"...

Also, you don't need to initialise i; if so, you should
set it to "0L", not "0". The call to malloc() could
also fail.

HTH,

--

If it ain't analogue, it ain't music.
#include <disclaimer.h>

WWW: www.rkdltd.demon.co.uk

by **Casper H.S. Dik - Network Security Engine** » Fri, 10 Apr 1998 04:00:00

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

>Dunno off the top of my head, but I'd be inclined not to
>try dereferencing a NULL pointer (thereby avoiding the
>segmentation violation in the first place). I don't
>understand the logic involving your use of "p"...

I assume *p (where p = 0) is to force a core dump.

Quote:>Also, you don't need to initialise i; if so, you should
>set it to "0L", not "0". The call to malloc() could
>also fail.

Uhm, "0" is a "0 pointer constant" (aka NULL)

0L is a long, and I'm not sure if you can assign a long 0 to a pointer.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

by **David McReynold** » Fri, 10 Apr 1998 04:00:00

First, I seem to be getting responses from thoughtful individuals who
want to tell me how to avoid the core. That's not the point. I want
the core. I need the core.

Secondly, everyone wants to comment on my use of p = 0;, advising me
that I would be better off using p = 0L;. The C FAQ is quite clear on
this matter.

1.1 What is this infamous null pointer, anyway?
. . .
A null pointer is conceptually different from an uninitialized pointer.
A null pointer is known not to point to any object; an uninitialized
pointer might point anywhere. See also questions 3.1, 3.13, and 17.1.
. . .
References: K&R I Sec. 5.4 pp. 97-8; K&R II Sec. 5.4 p. 102; H&S Sec.
5.3 p. 91; ANSI Sec. 3.2.2.3 p. 38.

1.2 How do I "get" a null pointer in my programs?
According to the language definition, a constant 0 in a pointer context
is converted into a null pointer at compile time. That is, in an
initialization, assignment, or comparison when one side is a variable or
expression of pointer type, the compiler can tell that a constant 0 on
the other side requests a null pointer, and generate the correctly-typed
null pointer value. Therefore, the following fragments are perfectly
legal:

char *p = 0;

if(p != 0)

. . .
References: K&R I Sec. A7.7 p. 190, Sec. A7.14 p. 192; K&R II Sec. A7.10
p. 207, Sec. A7.17 p. 209; H&S Sec. 4.6.3 p. 72; ANSI Sec. 3.2.2.3 .

Now that it is painfully clear that the program is correct as designed
let me re-ask my original question in more detail.

When compiling "cc -g foo.c -o foo" and running foo, the core file size
on AIX 3.2.5 is appx 19kb. When compiling "cc -g foo.c -o foo" and
running foo the core file size is appx 5Mb on HPUX 10.20.

So, since it is obvious that AIX is creating a partial core (the system
ulimits have been checked), how do I force AIX to create a full core.

dlm

> How can I get the operating system to provide a full core for the
> following program?

> int main()
> {
> long i = 0;
> char * p = 0;
> long a[1000000];
> char *cp;
> cp = (char*)malloc(1000000);
> for(i = 1; i < 1000000; i++)
> {
> a[i] = i;
> *cp = 0x41;
> }
> *p = 1;
> return 0;
> }

> The core file is always 26k even though I touched both the array and the
> char*.

by **Andrew Giert** » Fri, 10 Apr 1998 04:00:00

David> How can I get the operating system to provide a full core for
David> the following program?
[...]
David> The core file is always 26k even though I touched both the
David> array and the char*.

This wouldn't be on AIX by any chance? One of its little, ahem,
"features" is that only the stack is dumped unless you use sigaction
to set SA_FULLDUMP for the signal that caused the core.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **Michael Wil** » Fri, 10 Apr 1998 04:00:00

> When compiling "cc -g foo.c -o foo" and running foo, the core file size
> on AIX 3.2.5 is appx 19kb. When compiling "cc -g foo.c -o foo" and
> running foo the core file size is appx 5Mb on HPUX 10.20.

> So, since it is obvious that AIX is creating a partial core

It's not obvious yet to me. Have you verified the integrity of the
core file? Does the de* work correctly with it?

It's entire possible that the system doesn't want to bother writing
out all that uninitialized memory that's never been accessed. That
doesn't necessarily make the core file invalid.

Sorry, I couldn't attempt to duplicate this and test my questions
myself. The AIX box I have access to isn't well right now.

- Michael

by **David McReynold** » Fri, 10 Apr 1998 04:00:00

AIX 3.2.5 which I cannot get to work properly no matter what I do to the
sigaction struct. Things are different on AIX 4.2. There, the default
is to do a partial core dump and setting the sigaction to SA_FULLDUMP
will make the os dump all the process's memory. On 3.2.5 it nicely
ignores sa.sa_flags |= SA_FULLDUMP and always does a partial.

> David> How can I get the operating system to provide a full core for
> David> the following program?
> [...]
> David> The core file is always 26k even though I touched both the
> David> array and the char*.

> This wouldn't be on AIX by any chance? One of its little, ahem,
> "features" is that only the stack is dumped unless you use sigaction
> to set SA_FULLDUMP for the signal that caused the core.

> --
> Andrew.

> comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
> or <URL: http://www.whitefang.com/unix/>

by **David McReynold** » Fri, 10 Apr 1998 04:00:00

I have new information.

I have a program to read the core header which will indicate full or
partial. Also, I modified the test program.

#include <stdio.h>
#include <signal.h>

int main()
{
struct sigaction sa_in;
long i = 0;
char * p = 0; /* point to null */
char *cp;

#if 1
sa_in.sa_flags |= SA_FULLDUMP;
sigaction(SIGSEGV, &sa_in, &sa_out);
sigaction(SIGBUS, &sa_in, &sa_out);
#endif

if(NULL == (cp = (char*)malloc(1000000)))
{
fprintf(stderr, "malloc failed\n");
return -1;
}

for(i = 1; i < 1000000; i++)
{
*cp = 0x41;
}
*p = 1; /* create core file */
return 0;

Quote:}

On AIX 3.2.5
Signal Number : 11
Dump Type : partial dump
Ublock : valid
Ustack : valid
One or more modules : yes
Truncated : no

On AIX 4.2
Signal Number : 11
Dump Type : full dump
Ublock : valid
Ustack : valid
One or more modules : yes
Truncated : yes

> How can I get the operating system to provide a full core for the
> following program?

> int main()
> {
> long i = 0;
> char * p = 0;
> long a[1000000];
> char *cp;
> cp = (char*)malloc(1000000);
> for(i = 1; i < 1000000; i++)
> {
> a[i] = i;
> *cp = 0x41;
> }
> *p = 1;
> return 0;
> }

> The core file is always 26k even though I touched both the array and the
> char*.

by **Andrew Giert** » Fri, 10 Apr 1998 04:00:00

David> AIX 3.2.5 which I cannot get to work properly no matter what I
David> do to the sigaction struct. Things are different on AIX 4.2.
David> There, the default is to do a partial core dump and setting
David> the sigaction to SA_FULLDUMP will make the os dump all the
David> process's memory. On 3.2.5 it nicely ignores sa.sa_flags |=
David> SA_FULLDUMP and always does a partial.

Yuk.

Have you asked on the AIX group? (comp.unix.aix)

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **David McReynold** » Fri, 10 Apr 1998 04:00:00

When I lowered my allocation to about 100k (I took 1 zero out of the
malloc), suddenly all is well on the AIX 3.2.5 box. So, I figure maybe
the ulimits are different on the two boxes.

aix3.2.5
ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2048

aix4.2
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2048

Alas, back to the drawing board.

> I have new information.

> I have a program to read the core header which will indicate full or
> partial. Also, I modified the test program.

> #include <stdio.h>
> #include <signal.h>

> int main()
> {
> struct sigaction sa_in;
> long i = 0;
> char * p = 0; /* point to null */
> char *cp;

> #if 1
> sa_in.sa_flags |= SA_FULLDUMP;
> sigaction(SIGSEGV, &sa_in, &sa_out);
> sigaction(SIGBUS, &sa_in, &sa_out);
> #endif

> if(NULL == (cp = (char*)malloc(1000000)))
> {
> fprintf(stderr, "malloc failed\n");
> return -1;
> }

> for(i = 1; i < 1000000; i++)
> {
> *cp = 0x41;
> }
> *p = 1; /* create core file */
> return 0;
> }

> On AIX 3.2.5
> Signal Number : 11
> Dump Type : partial dump
> Ublock : valid
> Ustack : valid
> One or more modules : yes
> Truncated : no

> On AIX 4.2
> Signal Number : 11
> Dump Type : full dump
> Ublock : valid
> Ustack : valid
> One or more modules : yes
> Truncated : yes

> > How can I get the operating system to provide a full core for the
> > following program?

> > int main()
> > {
> > long i = 0;
> > char * p = 0;
> > long a[1000000];
> > char *cp;
> > cp = (char*)malloc(1000000);
> > for(i = 1; i < 1000000; i++)
> > {
> > a[i] = i;
> > *cp = 0x41;
> > }
> > *p = 1;
> > return 0;
> > }

> > The core file is always 26k even though I touched both the array and the
> > char*.

by **Bjorn Ree** » Sat, 11 Apr 1998 04:00:00

> When I lowered my allocation to about 100k (I took 1 zero out of the
> malloc), suddenly all is well on the AIX 3.2.5 box. So, I figure maybe
> the ulimits are different on the two boxes.

Or if you tried on two different accounts, the ulimits are different
for the two users. Start "smit users" and select "Change / Show
Characteristics of a User". Note that there are two kind of limits,
soft limits and hard limits.

Quote:> > int main()
> > {
> > struct sigaction sa_in;
> > long i = 0;
> > char * p = 0; /* point to null */
> > char *cp;

sa_in must be cleared, and you must set the SIG_DFL as handler
(although I don't expect this to solve your problem.)

Quote:> > #if 1
> > sa_in.sa_flags |= SA_FULLDUMP;
> > sigaction(SIGSEGV, &sa_in, &sa_out);
> > sigaction(SIGBUS, &sa_in, &sa_out);
> > #endif
> > *p = 1; /* create core file */

Another neat way is strcpy(NULL,"");

Very Computer

core too small

core too small

core too small

core too small

core too small

core too small

core too small

core too small

core too small

core too small

core too small

core too small