Segmentation fault in gdb

[yinglcs]

Hi,

i get this segmentation fault in my c++ program:

My question is 'it shows inMethodStr is not null, how come this can
have *inMethodStr.Ptr segmentation fault?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229927536 (LWP 16203)]
0x0806a1ee in RTSPProtocol::GetMethod (inMethodStr=@0xb6b0b6b0)
at Protocol.cpp:58
58 switch(*inMethodStr.Ptr)

Thank you for any help.

 

[Neelesh Bodas]

Hi,

i get this segmentation fault in my c++ program:

My question is 'it shows inMethodStr is not null, how come this can
have *inMethodStr.Ptr segmentation fault?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229927536 (LWP 16203)]
0x0806a1ee in RTSPProtocol::GetMethod (inMethodStr=@0xb6b0b6b0)
at Protocol.cpp:58
58 switch(*inMethodStr.Ptr)

Thank you for any help.

inMethodStr is not null doesnot mean it points to the properly
initialized object or object containing valid data.


Posting relevant piece of code might help.

 

[Ron Natalie]

Hi,

i get this segmentation fault in my c++ program:

My question is 'it shows inMethodStr is not null, how come this can
have *inMethodStr.Ptr segmentation fault?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229927536 (LWP 16203)]
0x0806a1ee in RTSPProtocol::GetMethod (inMethodStr=@0xb6b0b6b0)
at Protocol.cpp:58
58 switch(*inMethodStr.Ptr)

Thank you for any help.

In inMethodStr is something that can have . applied to it
(that is a class). It won't be null. Chances are
inMethodStr.Ptr is either a null pointer or points to
something other than a valid object.

 

[Andre Kostur]

Hi,

i get this segmentation fault in my c++ program:

My question is 'it shows inMethodStr is not null, how come this can
have *inMethodStr.Ptr segmentation fault?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229927536 (LWP 16203)]
0x0806a1ee in RTSPProtocol::GetMethod (inMethodStr=@0xb6b0b6b0)
at Protocol.cpp:58
58 switch(*inMethodStr.Ptr)

Thank you for any help.

How would we know? We can't see the rest of the code. Please post a
minimal, compilable example that shows the problem.

Offhand the address of inMethodStr is suspicious because it has a repeating
pattern (0xb6b0b6b0). This may suggest that you are using and/or passing
an uninitialized variable into GetMethod. Then you use the . operator on
that object, and Undefined Behaviour occurs (effectively dereferencing a
pointer to who-knows-where).

 

[Martijn van Buul]

* Ron Natalie:

In inMethodStr is something that can have . applied to it
(that is a class). It won't be null.

It *shouldn't* be NULL, but if I would do something like

struct SomeStruct
{
int foo;
int bar;
};

void SomeFunction (SomeStruct &pInStruct)
{
switch (pInStruct.foo)
{
[...]
}
};

int main(void)
{
SomeStruct *SueMe = 0;
SomeFunction(*SueMe);
}

Then 'pInStruct' *WILL* be NULL. And yes, I know, undefined behaviour, which
most definately *includes* being caught in a debugger.