C Src code giving CORE dump

[LeoThe13th]

Hi,
I am migrating my applciation from 32bit to 64bit. AFter successful compilation executable is giving core dump. After using Debugging statement i found the point of failure.

static char *PIDfilename;

PIDfilename = (char *) malloc(strlen("var/") + strlen(processName) + strlen(".pid") + 1);

*PIDfilename = '\0';

strcat(PIDfilename, "var/");
strcat(PIDfilename, processName);
strcat(PIDfilename, ".pid");

EOC

line where \0 is assign is giving core dump I have tried with NULL, strcpy..all statement is fiving core dump.
Can anyone suggest on this.
Thanks
Bhushan

[Matti_Kurkela]

I assume this is a snippet of the actual code, with a lot of things omitted. It certainly isn't a standalone example that could be compiled on its own to demonstrate the problem.

Things to check:

- Is the "processName" variable properly initialized at the point malloc() is executed?

- Did the malloc() operation complete successfully, or did it fail?

(If it failed, the assignment is doomed to fail. The application should at least detect this and try to exit in a controlled manner, preferably after outputting a meaningful error message.)

- Is there anything in between the malloc() operation and the assignment to "*PIDfilename" that might corrupt the value of the "PIDfilename" pointer?

(In the code you have shown, there is nothing. But this code is obviously incomplete - have you snipped away something from between these lines?)

MK

[LeoThe13th]

I have attached the code. This code when compiled with 32bit mode then it is successfully executed.
But when i compiled with 64bit then attached code is not working and giving core dump.

This a complete code.

[Steven Schweda · Accepted solution]

My HP-UX system is down right now, but on
VMS, you seem to be missing some crucial
header files. For example:

alp $ cc 313166.C_ORIG

PIDfilename = (char *) malloc(strlen("/EEH/var/") + strlen(processName)
+ strlen(".pid") + 1);
...............................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "malloc" is implicitly declared as a function.
at line number 24 in file ALP$DKA0:[SMS.ITRC]313166.C_ORIG;1
[...]


If your compiler thinks that malloc() is an
"int", then you might losing 32 bits worth of
pointer there. could help.

How are you compiling this without getting a
bunch of warnings?

[Laurent Menase]

if you do not include stdlib.h, then malloc() return a int (32 bits) and not a long or void *.

So you malloc result is truncated.
you can also do

extern void * malloc(int);

[Steven Schweda]

> How are you compiling this without getting a
> bunch of warnings?

I'm still wondering about this.

[LeoThe13th]

Thanks FOr ur valuble comments, I have included the stdlib.h in my test code and it seems the problem is fixed. Now i am implementing in Applcation source code and going to run the application.
If any issue arise will update.

Anyway after including the stdlib warning messge has gone.
Thanks
Bhushan

[Steven Schweda]

> Anyway after including the stdlib warning
> messge has gone.

Perhaps that warning, whatever it was, was
trying to tell you something important. You
learned the lesson here, right?

[Dennis Handly]

If you compile this on aCC6, you will get an error if you don't have a prototype for heap routines, because of your issue.

Also, you can use +w64bit and +wlint to check for clean programs.

If you are still on PA, you can download cadvise to do the same things:
http://www.hp.com/go/cadvise

>strlen("var/")

You can optimize this to:
(sizeof("var/")-1)

*PIDfilename = '\0';
strcat(PIDfilename, "var/");

Instead of doing this null assignment, you should change the first to strcpy(3).

[LeoThe13th]

Thanks everyone...

[dirk dierickx]

hmm, problems like this should not ever happen. i took a look at the source file and well, it is a small piece of code and it doesn't do complicated things.

for things like this you should simply use a scripting language like perl or python. you could probably turn it into a shell script just as well.

i used to be pretty good at C, but i don't see the need to use it anymore. for admin work there is nothing that can't be done with shell and perl scripting.

even when i fiddle around with desktop apps on linux, this is written in python (with glade/gtk), nobody notices the difference.

it's so easy, fast and you don't have to worry about things like pointers and memory allocations.

[Dennis Handly]

>Dirk: it is a small piece of code and it doesn't do complicated things.

Yes but it must be a small fragment since there would be no reason to compile with +DD64.

[dirk dierickx]

no reason, yes, but that doesn't make it true.

i'm saying, sometimes people do things out of habbit or because they read it somewhere and applied it without knowing what all the options stand for.