Signal 11 error (core)

[rohityogi]

This statement gives core dump

if( pError->pFileName[0] != '\0' )

can someone suggest why ?

This statement was failing in all our unix environments so we changed
it to:

if( !(pError->pFunctionName == NULL))

It worked for some environments then now again it failed in 1
environment.

Any idea ?

All memory allocation have been done.

 

[Joona I Palaste]

(e-mail address removed) scribbled the following:

This statement gives core dump

if( pError->pFileName[0] != '\0' )

can someone suggest why ?

This statement was failing in all our unix environments so we changed
it to:

if( !(pError->pFunctionName == NULL))

Well, if pError->pFunctionName is NULL, then no wonder doing anything
at all with pError->pFileName[0] will fail. Have you read a C textbook?

It worked for some environments then now again it failed in 1
environment.

Any idea ?

Well, it could be that pError itself is NULL.

All memory allocation have been done.

And have you checked if it has succeeded?

 

[Ben Pfaff]

Well, if pError->pFunctionName is NULL, then no wonder doing anything
at all with pError->pFileName[0] will fail.

How does that follow?

 

[Joona I Palaste]

Well, if pError->pFunctionName is NULL, then no wonder doing anything
at all with pError->pFileName[0] will fail.

How does that follow?

Well, if you're going to be pedantic, it doesn't. It causes UB, which
does not necessarily mean failure. But I figured that on the OP's
system, it would fail.

 

[Ben Pfaff]

Well, if pError->pFunctionName is NULL, then no wonder doing anything
at all with pError->pFileName[0] will fail.

How does that follow?

Well, if you're going to be pedantic, it doesn't. It causes UB, which
does not necessarily mean failure. But I figured that on the OP's
system, it would fail.

How does knowing that
pError->pFunctionName is a null pointer tell you that
pError->pFilename is not a valid pointer?

 

[Joona I Palaste]

Well, if pError->pFunctionName is NULL, then no wonder doing anything
at all with pError->pFileName[0] will fail.

How does that follow?

Well, if you're going to be pedantic, it doesn't. It causes UB, which
does not necessarily mean failure. But I figured that on the OP's
system, it would fail.

How does knowing that
pError->pFunctionName is a null pointer tell you that
pError->pFilename is not a valid pointer?

Argh. Now I feel stupid. I need either to get new glasses or to stop
reading comp.lang.c late in the evening.

 

[Marc Olzheim]

This statement gives core dump

if( pError->pFileName[0] != '\0' )

can someone suggest why ?

pError->pFileName is probably not useful (anymore?)... It could be a
NULL pointer for instance.

pError itself seems to be valid, since you can dereference it.

Zlo

 

[Christopher Benson-Manica]

<[email protected]>
(e-mail address removed) wrote:

I am not a guru, so add grains of salt as needed.

if( pError->pFileName[0] != '\0' )

can someone suggest why ?

1. pError->pFileName is a null pointer.
2. You free()'d pError or pError->pFileName.

if( !(pError->pFunctionName == NULL))

What's wrong with

if( pError->pFunctionName != NULL )

?

It worked for some environments then now again it failed in 1
environment.

Any idea ?

Sounds like 2) above - using a pointer after you've free()'d it causes
undefined behavior, one common manifestation of which is "works on
platform X but not on platform Y".

 

[rohityogi]

I found the problem pError->pFileName & pError->pFunctionName was not
alocated memory. Actually it is a huge code and pError is passed from
multiple places and programs so I was finding difficult to back track.
I reached a point where these two vars were not allocated memory and
now we are checking first char of string to hold '\0' which is wrong.

<[email protected]>
(e-mail address removed) wrote:

I am not a guru, so add grains of salt as needed.

if( pError->pFileName[0] != '\0' )

can someone suggest why ?

1. pError->pFileName is a null pointer.
2. You free()'d pError or pError->pFileName.

if( !(pError->pFunctionName == NULL))

What's wrong with

if( pError->pFunctionName != NULL )

?

It worked for some environments then now again it failed in 1
environment.

Any idea ?

Sounds like 2) above - using a pointer after you've free()'d it causes
undefined behavior, one common manifestation of which is "works on
platform X but not on platform Y".