LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 07-25-2010, 09:22 PM   #1
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Rep: Reputation: 0
SEGMENTATION FAULT using gcc 4.4.4 -O2 , works with gcc 4.1.0 -O2 or gcc 4.4.4 -O1


Hi,
I'm trying to update a relatively old software to be used with new 64-bit systems and also new version of gcc. Becuase the original software is written for 32-bit systems, I decide to use controlled data types which are the same on both 64 bit and 32 bit Machines. I change the code according to these new defined types, Here is the situation:
1- As I expect everything works on 32-bit machine.
2-If I use gcc 4.1.0 on 64-bit Machine everything is working
3-If I use gcc 4.4.4 on 64-bit Machine Segmentation Fault would occur! (Optimization O2)
4-If I use gcc 4.4.4 on 64- bit Machine with -O everything works!!

Here is the output of Valgrind:
==13412==
==13412==
==13412== Process terminating with default action of signal 11 (SIGSEGV)
==13412== Access not within mapped region at address 0x700000008
==13412== at 0x409F29: SysString::clear(Integral::CMODE) (sstr_03.cc:1623)
==13412== by 0x40B73D: SysString::assign(unsigned char, wchar_t const*) (sstr_03.cc:838)
==13412== by 0x403474: SysString::diagnose(Integral:EBUG) (sstr_02.cc:221)
==13412== by 0x401E1C: main (in /usr/local/isip/tools/ifc/class/system/SysString/SysString.exe)
==13412== If you believe this happened as a result of a stack
==13412== overflow in your program's main thread (unlikely but
==13412== possible), you can try to increase the size of the
==13412== main thread stack using the --main-stacksize= flag.
==13412== The main thread stack size used in this run was 16777216.
==13412==
==13412== For counts of detected and suppressed errors, rerun with: -v


Why I am getting Segmentation Error in case 3?

tnx

Last edited by amir1981; 07-25-2010 at 09:23 PM.
 
Old 07-25-2010, 09:40 PM   #2
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Hi -

As I'm sure you know, just because some code happens to run without crashing, doesn't necessarily mean that code is "correct". There could have been a latent bug there since Day One.

On the other hand (as Valgrind is reporting), maybe you're getting a stack overflow. Certainly worth instrumenting and looking for:

It looks like the code in question is trying to emulate Windows MFC functionality (which, itself, is probably fraught with danger ).

STRONG SUGGESTION:
1. See if you can reproduce the problem with "-g"

2. If so, see if you can troubleshoot whether your input values are correct and your data structures are uncorrupted, and your stack OK under GDB.

3. You might also be interested in using libsigsegv() for your troubleshooting:

http://savannah.gnu.org/projects/libsigsegv/

'Hope that helps .. PSM
 
Old 07-25-2010, 09:51 PM   #3
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by amir1981 View Post
Hi,
I'm trying to update a relatively old software to be used with new 64-bit systems and also new version of gcc. Becuase the original software is written for 32-bit systems, I decide to use controlled data types which are the same on both 64 bit and 32 bit Machines. I change the code according to these new defined types, Here is the situation:
1- As I expect everything works on 32-bit machine.
2-If I use gcc 4.1.0 on 64-bit Machine everything is working
3-If I use gcc 4.4.4 on 64-bit Machine Segmentation Fault would occur! (Optimization O2)
4-If I use gcc 4.4.4 on 64- bit Machine with -O everything works!!

Here is the output of Valgrind:
==13412==
==13412==
==13412== Process terminating with default action of signal 11 (SIGSEGV)
==13412== Access not within mapped region at address 0x700000008
==13412== at 0x409F29: SysString::clear(Integral::CMODE) (sstr_03.cc:1623)
==13412== by 0x40B73D: SysString::assign(unsigned char, wchar_t const*) (sstr_03.cc:838)
==13412== by 0x403474: SysString::diagnose(Integral:EBUG) (sstr_02.cc:221)
==13412== by 0x401E1C: main (in /usr/local/isip/tools/ifc/class/system/SysString/SysString.exe)
==13412== If you believe this happened as a result of a stack
==13412== overflow in your program's main thread (unlikely but
==13412== possible), you can try to increase the size of the
==13412== main thread stack using the --main-stacksize= flag.
==13412== The main thread stack size used in this run was 16777216.
==13412==
==13412== For counts of detected and suppressed errors, rerun with: -v


Why I am getting Segmentation Error in case 3?

tnx
If not yet, always use

-Wall -Wextra -Wformat=2

during compilation - sometimes warnings produced by the compiler give the clue.
 
Old 07-25-2010, 09:55 PM   #4
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by paulsm4 View Post
Hi -

As I'm sure you know, just because some code happens to run without crashing, doesn't necessarily mean that code is "correct". There could have been a latent bug there since Day One.

On the other hand (as Valgrind is reporting), maybe you're getting a stack overflow. Certainly worth instrumenting and looking for:

It looks like the code in question is trying to emulate Windows MFC functionality (which, itself, is probably fraught with danger ).

STRONG SUGGESTION:
1. See if you can reproduce the problem with "-g"

2. If so, see if you can troubleshoot whether your input values are correct and your data structures are uncorrupted, and your stack OK under GDB.

3. You might also be interested in using libsigsegv() for your troubleshooting:

http://savannah.gnu.org/projects/libsigsegv/

'Hope that helps .. PSM
Hey,
Actually, I have checked different stack sizes already and it is not helping.
This code is a part of a bigger code and is relatively complex system


I have complied with -g and it is the result of gdb:
gdb) r
Starting program: /usr/local/isip/tools/ifc/class/system/SysString/SysString.exe
diagnosing class SysString:
testing required public methods...
<SysString::str1> value_d = (16 >= 16) "hello my name is"
<SysString::str2> value_d = (4 >= 4) "rjck"
<SysString::str3> value_d = (100 >= 0) ""
<SysString::str4> value_d = (4 >= 4) "rjck"
testing class-specific public methods: extensions to required methods...

Program received signal SIGSEGV, Segmentation fault.
SysString::clear (this=0x7f00000000, cmode_a=Integral::RESET) at sstr_03.cc:1623
1623 if (capacity_d > 0) {
Current language: auto; currently c++
(gdb)


I will work with libsigsegv to see if it can help or not!!!

anyway, thanks for the reply
 
Old 07-25-2010, 09:57 PM   #5
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Sergei Steshenko View Post
If not yet, always use

-Wall -Wextra -Wformat=2

during compilation - sometimes warnings produced by the compiler give the clue.
I have just used -Wall , but thanks for reminding I would add -Wextra -Wformat=2 too Maybe some useful information comes out
 
Old 07-25-2010, 10:36 PM   #6
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,125

Rep: Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119
Quote:
Originally Posted by amir1981 View Post
2-If I use gcc 4.1.0 on 64-bit Machine everything is working
3-If I use gcc 4.4.4 on 64-bit Machine Segmentation Fault would occur! (Optimization O2)
4-If I use gcc 4.4.4 on 64- bit Machine with -O everything works!!
A significant fraction of problems posted with descriptions like that turn out to by strict-aliasing problems.

To find out whether it is a strict-aliasing problem, replace the -O2 option with
-O2 -fno-strict-aliasing

If that fixes it, the problem was probably strict-aliasing (though that wouldn't be certain). If -fno-strict-aliasing doesn't fix the problem, then the problem definitely wasn't strict-aliasing.

If the problem is strict-aliasing, it is best to find and fix that error each place where it occurs in your code. But it large old programs that usually isn't practical, so -fno-strict-aliasing becomes a long term part of your compile command.

Last edited by johnsfine; 07-25-2010 at 10:40 PM.
 
Old 07-25-2010, 10:44 PM   #7
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by johnsfine View Post
A significant fraction of problems posted with descriptions like that turn out to by strict-aliasing problems.

To find out whether it is a strict-aliasing problem, replace the -O2 option with
-O2 -fno-strict-aliasing

If that fixes it, the problem was probably strict-aliasing (though that wouldn't be certain). If -fno-strict-aliasing doesn't fix the problem, then the problem definitely wasn't strict-aliasing.

If the problem is strict-aliasing, it is best to find and fix that error each place where it occurs in your code. But it large old programs that usually isn't practical, so -fno-strict-aliasing becomes a long term part of your compile command.
Unfortunately it is no the case, code is already compiled with -fno-strict-aliasing
 
Old 07-25-2010, 11:11 PM   #8
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,125

Rep: Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119
Quote:
Originally Posted by amir1981 View Post
Program received signal SIGSEGV, Segmentation fault.
SysString::clear (this=0x7f00000000, cmode_a=Integral::RESET) at sstr_03.cc:1623
1623 if (capacity_d > 0) {
Is capactity_d a member variable of SysString? Otherwise what is it?

Seg faults should be pretty easy to understand when you catch them this way in GDB. The this pointer 0x7f00000000 looks a little improbable, but not definitely wrong. GDB commands can be used to examine the *this object and/or the contents of memory at 0x7f00000000 to see whether that pointer is wrong.

I don't know whether your Valgrind results were run with the same addresses used as your GDB results. The faulting address reported by Valgrind 0x700000008 seems quite unlikely for that line of code (a simple read of capactity_d) and the GDB reported value of the this pointer.

If you post a bit more of the source of SysString::clear, that might make the problem obvious.

If you know any asm, it is very effective to look at some disassembly and register values in GDB at the point of the seg fault.

The seg fault means some address was bad. You need to figure out what address was bad and what the code was supposed to be doing with that address and why it had a wrong value instead. All that should be pretty easy to find in GDB at the point of the seg fault.
 
Old 07-26-2010, 12:51 AM   #9
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by johnsfine View Post
Is capactity_d a member variable of SysString? Otherwise what is it?

Seg faults should be pretty easy to understand when you catch them this way in GDB. The this pointer 0x7f00000000 looks a little improbable, but not definitely wrong. GDB commands can be used to examine the *this object and/or the contents of memory at 0x7f00000000 to see whether that pointer is wrong.

I don't know whether your Valgrind results were run with the same addresses used as your GDB results. The faulting address reported by Valgrind 0x700000008 seems quite unlikely for that line of code (a simple read of capactity_d) and the GDB reported value of the this pointer.

If you post a bit more of the source of SysString::clear, that might make the problem obvious.

If you know any asm, it is very effective to look at some disassembly and register values in GDB at the point of the seg fault.

The seg fault means some address was bad. You need to figure out what address was bad and what the code was supposed to be doing with that address and why it had a wrong value instead. All that should be pretty easy to find in GDB at the point of the seg fault.
capacity_d is a member variable of SysString
Here is the snap of the code:

Code:
// method: clear
//
// arguments:
//  Integral::CMODE cmode: (input) clear mode 
//
// return: a bool8 value indicating status
//
// this method clears the string
//
bool8 SysString::clear(Integral::CMODE cmode_a) {

  // for release and free, ensure that memory is actually deleted
  //
  if (cmode_a >= Integral::RELEASE) {

    // delete all memory associated with this string
    //    
    freeMem();

    // assign null string to class data
    //
    allocateMem();
  }

  // for reset and retain, just clear value
  //
  else {

    // make the string a zero-length string. 
    //
    if (capacity_d > 0) {
      value_d[0] = (unichar)NULL;
    }
  }

  // exit gracefully
  //
  return true;
}


Code:
// --------------------------------------------------------------
// these two methods have to be in the same file so they get the
// static constant NULL_STRING with the exact same address
// --------------------------------------------------------------

// method: allocateMem
//
// arguments: none
//
// return: a boolean value indicating status
//
// this method allocates memory for the string
//

bool8 SysString::allocateMem() {

  // either allocate the memory or assign it to the static null string
  //
  if (capacity_d > 0) {
    if (value_d != (unichar*)NULL) {
      return Error::handle(name(), L"allocateMem", Error::MEM,
			   __FILE__, __LINE__);
    }

    // allocate and initialize the memory
    //
    value_d = new unichar[capacity_d + 1];
    value_d[0] = (unichar)NULL;
  }
  else {
    if (value_d != (unichar*)NULL) {
      return Error::handle(name(), L"allocateMem", Error::MEM,
			   __FILE__, __LINE__);
    }

    // reset the capacity 
    //
    capacity_d = 0;

    // assign null string to class data
    //
    value_d = (unichar*)NULL_STRING;
  }

  // exit gracefully
  //
  return true;
}

// method: freeMem
//
// arguments: none
//
// return: a bool8 value indicating status
//
// this method deletes memory for the string
//
bool8 SysString::freeMem() {

  // possibly free memory associated with this string
  //
  if (capacity_d > 0) {
    if (value_d != (unichar*)NULL) {

      // release and initialize the pointer
      //
      delete [] value_d;
      value_d = (unichar*)NULL;
    }
    else {
      return Error::handle(name(), L"freeMem", Error::MEM, __FILE__, __LINE__);
    }
  }

  // if capacity is less than or equal to 0
  //
  else {
    if (value_d == (unichar*)NULL_STRING) {

      // initialize the ptr
      //
      value_d = (unichar*)NULL;
    }
    else {
      return Error::handle(name(), L"freeMem", Error::MEM, __FILE__, __LINE__);
    }

  }

  // reset the capacity
  //
  capacity_d = 0;

  // exit gracefully
  //
  return true;
}

// method: growMem
//
// arguments:
//  int32 new_size: (input) new size of memory required
//
// return: a bool8 value indicating status
//
// allocate more memory for the string, nondestructively
//
bool8 SysString::growMem(int32 new_size_a) {

  // see if we have to do anything
  //
  if (new_size_a <= capacity_d) {
    return true;
  }

  // if there is nothing in the old memory block, we don't have to
  // save any memory, just delete and reallocate
  //
  if (length() == 0) {
    freeMem();
    capacity_d = new_size_a;
    allocateMem();
  }
  else {

    // this is the only nontrivial case, we need to increase the size
    // of the memory without destroying existing contents. we do this
    // by creating a new string of the specified size, assigning this
    // new string to have our current value, and swapping the memory
    // pointers (so that the old buffer is deleted with the new
    // SysString)
    //
    SysString* tmp_str = new SysString(new_size_a);

    // assign tmp_str to have current values
    //
    tmp_str->assign(*this);

    // swap the memory pointers
    //
    swap(*tmp_str);

    delete tmp_str; 
  }
  
  // exit gracefully
  //
  return true;
}

Actually the error tends to move, for example if I comment out some part of the code it would appear somewhere else!

output of gdb and backtrace:
gdb) r
Starting program: /usr/local/isip/tools/ifc/class/system/SysString/SysString.exe
diagnosing class SysString:
testing required public methods...
<SysString::str1> value_d = (16 >= 16) "hello my name is"
<SysString::str2> value_d = (4 >= 4) "rjck"
<SysString::str3> value_d = (100 >= 0) ""
<SysString::str4> value_d = (4 >= 4) "rjck"
testing class-specific public methods: extensions to required methods...

Program received signal SIGSEGV, Segmentation fault.
SysString::clear (this=0x7f00000000, cmode_a=Integral::RESET) at sstr_03.cc:1623
1623 if (capacity_d > 0) {
Current language: auto; currently c++
(gdb) backtrace
#0 SysString::clear (this=0x7f00000000, cmode_a=Integral::RESET) at sstr_03.cc:1623
#1 0x000000000040b73e in SysString::assign (this=0x7f00000000, arg_a=27 '\033', fmt_a=<value optimized out>) at sstr_03.cc:838
#2 0x0000000000403475 in SysString::diagnose (level_a=<value optimized out>) at sstr_02.cc:221
#3 0x0000000000401e1d in main ()
(gdb)
 
Old 07-26-2010, 02:49 AM   #10
zirias
Member
 
Registered: Jun 2010
Posts: 361

Rep: Reputation: 59
Quote:
Originally Posted by amir1981 View Post
#1 0x000000000040b73e in SysString::assign (this=0x7f00000000, arg_a=27 '\033', fmt_a=<value optimized out>) at sstr_03.cc:838
As john already mentioned, the *this looks VERY suspect to me. Although it is inside the valid region where a heap object COULD be in x86_64 virtual address space, this would actually mean your heap was around 500 TB in size and the fact that the lower 32bit are all zeros is not that probable either

Try setting a breakpoint earlier and see where this pointer is coming from.

Last edited by zirias; 07-26-2010 at 02:51 AM.
 
Old 07-26-2010, 07:07 AM   #11
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,125

Rep: Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119
Quote:
Originally Posted by amir1981 View Post
Actually the error tends to move, for example if I comment out some part of the code it would appear somewhere else!
But that isn't what you're showing this time, right? You're showing the error in the same place.

An error that moves like that, usually is a memory clobber bug: The code with the actual bug uses some memory that doesn't belong to it. Then the error appears when the section of code that does own that memory uses it.

A memory clobber bug usually needs to be backtracked in two stages. First you need to follow the bad value (the this pointer in your example) back to the memory location where it was clobbered. Then you need to restart and set a data breakpoint to catch the real bug (In GDB I don't know how, nor even the correct terminology. I'm usually chasing such bugs in Visual Studio).

The info you posted makes it much more likely that the this pointer is bad (otherwise GDB is wrong about the line number, which is possible, but less likely). You also showed that the this pointer came through SysString::assign. So you should be looking in SysString::assign, or more likely the code that called it, for the point where this got clobbered.
 
Old 07-26-2010, 12:58 PM   #12
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
I have found something that might be related to the problem :
If use gdb and put a breakpoint just before the segmentation fault occurs in sstr_02.cc (at line 220) and then examine the value of "value_d" (value_d is a pointer to unichar) and then go one step into assign function and examine the "value_d" again I see this:
(gdb) r
Starting program: /usr/local/isip/tools/ifc/class/system/SysString/SysString.exe
testing class SysString
diagnosing class SysString:
testing required public methods...
<SysString::str1> value_d = (16 >= 16) "hello my name is"
<SysString::str2> value_d = (4 >= 4) "rjck"
<SysString::str3> value_d = (100 >= 0) ""
<SysString::str4> value_d = (4 >= 4) "rjck"
testing class-specific public methods: extensions to required methods...

Breakpoint 1, SysString::diagnose (level_a=<value optimized out>) at sstr_02.cc:221
(gdb) p num.value_d
$3 = (unichar *) 0x61fcb0

(gdb) s
SysString::assign (this=0x7f00000000, arg_a=27 '\033', fmt_a=0x41afd8) at sstr_03.cc:818
(gdb) p value_d
$4 = (unichar *) 0x0

(gdb)


on 32 bit system it like this:
(gdb) r
Starting program: /home/amir/local/isip/tools/system-ifc/class/system/SysString/SysString.exe
testing class SysString
diagnosing class SysString:
testing required public methods...
testing class-specific public methods: extensions to required methods...

Breakpoint 1, SysString::diagnose (level_a=Integral::BRIEF) at sstr_02.cc:221
(gdb) p num.value_d
$3 = (unichar *) 0x81672e8 L"27"

(gdb) s
SysString::assign (this=0xbfffeb84, arg_a=27 '\033', fmt_a=0x8063ac0 L"asdf = %u xyz") at sstr_03.cc:828
(gdb) p value_d
$4 = (unichar *) 0x81672e8 L"27"

(gdb)


As you can see for some reason "value_d" is pointing the NULL in the first case which is wrong, How this could happen?

Last edited by amir1981; 07-26-2010 at 01:00 PM.
 
Old 07-26-2010, 02:17 PM   #13
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,125

Rep: Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119
Quote:
Originally Posted by amir1981 View Post
As you can see for some reason "value_d" is pointing the NULL in the first case which is wrong, How this could happen?
You haven't provided the kind of information that would allow us to determine that.

Meanwhile, there is something strange in what you just provided. Can you explain this:

In your 64 bit version line 221 in SysString::diagnose called a version of SysString::assign at line 818. But in your 32 bit version line 221 in SysString::diagnose called an apparently different version of SysString::assign at line 828.

If you don't have a good explanation for that, post the area around each of those lines (around 221 in sstr_02.cc as well as around 818 through 828 in sstr_03.cc).
 
Old 07-26-2010, 02:29 PM   #14
amir1981
LQ Newbie
 
Registered: Jul 2010
Posts: 19

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by johnsfine View Post
You haven't provided the kind of information that would allow us to determine that.

Meanwhile, there is something strange in what you just provided. Can you explain this:

In your 64 bit version line 221 in SysString::diagnose called a version of SysString::assign at line 818. But in your 32 bit version line 221 in SysString::diagnose called an apparently different version of SysString::assign at line 828.

If you don't have a good explanation for that, post the area around each of those lines (around 221 in sstr_02.cc as well as around 818 through 828 in sstr_03.cc).
Hi thanks for the fast response what kind of details should I provide?
Here is the code:

bool8 SysString::assign(byte8 arg_a, const unichar* fmt_a){<---Line 818

// allocate a static buffer for printing
//
static char buf[MAX_LENGTH];
static char fmt[MAX_LENGTH];
static char* fmt_ptr;

// check the arguments
//
if (fmt_a == (unichar*)NULL) { <---- Line 828
return Error::handle(name(), L"assign", Error::ARG, __FILE__, __LINE__);
}

SysString temp(fmt_a);
temp.getBuffer((byte8*)fmt, MAX_LENGTH);
fmt_ptr = fmt;

// clear out the current value
//
clear(Integral::RESET);

// create and possibly assign the string
//
if (sprintf(buf, fmt_ptr, (uint32)arg_a) > 0) {
assign((byte8*)buf);
return true;
}

// exit gracefully
//
return false;
}


I think it is a gdb issue that shows line 828 instead of 818
 
Old 07-26-2010, 03:06 PM   #15
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,125

Rep: Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119Reputation: 1119
OK, now I see I misunderstood GDB output regarding 818 vs. 828. That is just a difference in the optimizer behavior of the two compiles.

I don't know how much to trust GDB regarding the values of this and value_d when stopped at line 818. Generally I don't trust any implausible variable values reported by GDB. GDB and/or the compiler are not very good at tracking which variables are in which registers and/or stack locations at which lines of the source code.

zirias expressed the opinion (that I mostly share) that 0x0x7f00000000 is an unreasonable value for this. You told me that value_d is a member of SysString so at line 818 value_d should be equivalent to this->value_d which (assuming this is invalid) should have been Cannot access memory at address rather than $4 = (unichar *) 0x0

If I were debugging it, I would poke around a bit more at that point to find out which, if any, of the apparently contradictory pieces of info represent the result of the bug you're looking for, vs. which represent wrong info displayed by GDB.

At 818 and maybe at an s further into that function, I would want to know what is:
this
&value_d
this->value_d
If those don't start to add up to something consistent, I'd look at disassembly of the code at that point and at register values and also try directly looking at memory at address 0x7f00000000
 
  


Reply

Tags
gcc, optimization, segmentation fault


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Segmentation Fault and Gcc compiler skarland Linux - Newbie 2 02-14-2007 10:52 AM
compiling in gcc goes well, gives segmentation fault jshine Programming 6 12-19-2004 02:08 AM
gcc, segmentation fault, though compiles... scratch09 Programming 5 11-20-2004 06:11 PM
Slackwaer 9.1 GCC Compiling Segmentation Fault kdepa Slackware 2 03-15-2004 07:31 PM
gcc / segmentation fault skeletal29 Linux - Software 0 05-05-2002 05:05 AM


All times are GMT -5. The time now is 04:17 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration