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]

ro*******@yahoo.com 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?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Holy Banana of this, Sacred Coconut of that, Magic Axolotl of the other."
- Guardian in "Jinxter"

[Ben Pfaff]

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

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

How does that follow?
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield

[Joona I Palaste]

Ben Pfaff <bl*@cs.stanford.edu> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield

[Ben Pfaff]

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Ben Pfaff <bl*@cs.stanford.edu> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

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?
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org

[Joona I Palaste]

Ben Pfaff <bl*@cs.stanford.edu> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Ben Pfaff <bl*@cs.stanford.edu> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> writes:
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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Keep shooting, sooner or later you're bound to hit something."
- Misfire

[Marc Olzheim]

ro*******@yahoo.com wrote:

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]

<11**********************@g14g2000cwa.googlegroups .com>
ro*******@yahoo.com 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".

--
Christopher Benson-Manica
ataru(at)cyberspace.org

[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.

Christopher Benson-Manica wrote:

<11**********************@g14g2000cwa.googlegroups .com>
ro*******@yahoo.com 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".

--
Christopher Benson-Manica
ataru(at)cyberspace.org