I'm noticing that whenever I am declaring or initializing int c = 0, I seem to get a segmentation fault. It is only when I comment out that particular line of my code that it works fine. Here is a portion of my code:
int a = 0;
int b = 0;
int c = 0;
struct alphabet{
int first;
char word[30];
};
I've tested my code with just a and b as my only integers. It only began giving me that the segmentation fault once I tried initializing c later on. I just don't understand why this would even happen. Can someone help me?
Thank you in advance!
Since you have posted a very short peace of code, it is hard to give you a concrete advise. Hovewer, let's try as for the 'average' case. All your three int variables are located at the stack frame. Thus, adding more variables like c you may move the location of the rest stack variables which may be defined later. In particular, if you instantiate an instance of your structure alphabet which has an array field word. Imagine what happens if you underrun it (out of baundary access to the left baundary of the array). In the case if this underrun overlaps the area where c is located and you write to it by initializing c, then potentially string operation on word may crash. So, my advise would be do a code review starting down from the this function. Focus is on using uninitialized variables, out of boundary access and hanging pointers in respect to stack variables. A good practice would also be to use some static code analysis tool. For more concrete hints you need to extend your question to give more details as is recommended in the comments above.
Related
Consider that I have a struct as below.
I want to reset this struct.
struct StProduct {
int weight;
int price[100];
StProduct():
weight( 0 ),
price( ) {}
};
This way to reset the struct is given in a lot of examples and works :
StProduct apple;
// some code ...
apple = StProduct();
Now we'll dynamically allocate. Is it valid to reset the struct like this:
StProduct* pbanana = new StProduct();
// some code ...
*pbanana = StProduct();
Or could it be that there is some undefined behavior involved?
Clarification of the embedded nature of the question:
The question is really only the one above, and can be answered as such.
People seem to be concerned about a Minimal, Complete, and Verifiable example.
Therefore let me add the following explanation:
My x86 unit tests with the code above work.
But on an embedded device (STM32 F427) with gcc 4.7.6, an RTOS and having the struct as permanent buffer in the core coupled memory, the line
*pbanana = StProduct();
in the code called every 100ms leads to a crash after roughly 30min, while commenting this line out has the device running for 3 days now.
This is why I was asking, if the code above might be associated with undefined behaviour. Since it apparently is not, I am thankful for the comments and have to look somewhere else - and my bet is on a compiler bug.
If someone has any idea how I can provide a Minimal, Complete, and Verifiable example that does not involve sending hardware to everyone, I'm all ears.
Your code doesn't cause memory corruption itself, but there may be some kind of work with uninitialized memory. Your approach works fine if everything is managed properly.
When you call int price[100]; it will allocate 100 ints of memory that price points to, but it doesn't say anything about the contents. If you want to make sure they are, for example, 0 after construction, you can initialize the array in the constructor:
StProduct() : weight(0) {
for(int i = 0; i < 100; ++ i)
price[i] = 0;
}
Your current approach does work though, the problem is most likely in another part of the code where it doesn't handle that the memory is uninitialized, unless you assume that the array is 0 initialized.
I have a problem with my code, it seems to fail in a weird way in release mode, debug mode works just fine.
I am out of ideas and clues. I would like to get a direction for what should i do.
So here is the problematic code:
static inline void FindPoint(Line *First,AABB *Second,point *Pt,int direction)
{
std::vector<point*> pntvec; ... }
When i call function FindPoint it is all fine and everything is set well.
But when i reach the vector initialization the First pointer is reset to the same address as the vector.
That causes unexpected behavior.
So i thought the problem was in the commonalities. Both Line and the vector are using the point structure.
Yet i was not able to find anything unusual.
here are the structures
typedef struct
{
double x;
double y;
}point;
typedef struct
{
double incline;
double y;
double x;
double c;
point start,finish;
}Line;
And here is the initialization of the data sent to parameter First:
Line *objvec = new Line;
so what could be the problem can any one tell?
Thank you in advance
Edit:
A better look at the code
http://pastebin.com/rki7EdM6
You're using pointers more heavily than you should for these simple types. Pointers and dynamic allocation are the likely sources of your undefined behavior. So a simple first step is to refactor and clean up your code, preferring stack variables and pass-by-reference for simple types. In all likelihood, the undefined behavior will go away, or the error will be easier to spot.
[Caveat: I can't get to pastebin, so I can't see your full code. Prefer simple examples right here on the site]
For example, your function signature should probably be this (I'm guessing about which parameter is the output)
static inline point FindPoint(const Line &First, const AABB &Second,int direction)
And
Line *objvec = new Line;
should just be
Line objvec;
etc, etc.
std::vector<point> pntvec;
is probably the most important. A vector of pointers is ok, but should be avoided if possible. One of the nice parts about standard containers is the auto-cleanup when the variable goes out of scope. You don't get that with a vector of pointers, since the vector doesn't know to call delete on every element. You have to do it yourself.
"so what could be the problem can any one tell?"
If such a situation occurs, the most probable reason is, you have hit undefined behavior in your code somewhere else.
I can't tell any more from the context and code you have posted. But using a tool like valgrind is likely to do this right on your service.
I've recently come across a very strange segfault while developing my application. Basically, if I add another variable to one of my structs, a segfault is caused upon execution, for no apparent reason. Removing this variable immediately solves the problem. The struct is as follows:
typedef struct Note {
char cNote;
unsigned int uiDuration;
unsigned int uiVelocity;
};
As soon as I add a
long lStartTime;
variable anywhere in the struct, the code compiles as usual but will throw a segmentation fault. GDB's backtrace is lost somewhere in some obscure WIN methods that I don't even use.
Any ideas?
Thanks!
I see several possible explanations:
Something somewhere assumes that the struct is of a certain size. Changing the size break things.
You might have a memory bug of some sort, which is brought to the surface by you changing the layout of things in memory. Try a tool like valgrind or Purify.
You are changing the struct in a header file, but are failing to rebuild all source files that use the struct.
Okay, I have a struct, TextBlock, that simulates moving blocks of text around the screen. Here's the header:
struct TextBlock
{
RECT textArea;
RECT rectArea;
double whatBlock;
double x;
double y;
double angle;
double speed;
double width;
double height;
char *word;
bool stuck;
};
When it's like this, everything works perfectly fine. The problem comes when I add another member that I need. The way it works is that I have two arrays of TextBlocks. The first is for moving ones, the second is for ones that don't move, signifying where the moving ones need to go. The words are all randomized from a sentence to a jumble, so this data member will be set (commented out) to the index of which static block belongs to the moving one so I know when it's in the right place.
int whatBlock;
After creating this, I go through all of the created objects and set
tb[i][j].whatBlock = 0; //same area as other data members being set, moving text
stb[i][j].whatBlock = 0; //static text block
When I try to run this, without doing anything else to the data member, it comes up with an error:
The instruction at [address] referenced memory at [different address]. The memory could not be "written".
Note that if I don't try to modify it, and just create the data member, it works.
At this point of almost being done and having tons of these kinds of problems, I'm getting a bit fed up with this program >.> Any help at all on this would be greatly appreciated.
EDIT: This issue is now fixed. I replied to the accepted answer with the explanation, but it poses another problem, even if it doesn't affect this program.
Force a rebuild of everything. You may have an object file that is out-of-date with respect to the header file that defines TextBlock
If that doesn't fix it, run your program under a debugger and see what the faulting instruction is. Either that will allow you to fix the program, or you can ask again with mroe informatin.
Without you posting more code, I can only tell that you likely have a memory corruption bug in your program - i.e. you are reading or writing beyond the end of allocated memory.
If you post more code, I'll edit this answer accordingly.
I can't really give advices since we cannot access the complete source code.
Anyway, I can suggest you that it may be not in the struct TextBlock where really hides the bug. For instance, every access to TextBlock's member means that you are accessing to this hidden variable.
If this pointer is corrupted, you may experience problem where you don't expect it, leading you to search in the wrong places.
I have a piece of templated code that is never run, but is compiled. When I remove it, another part of my program breaks.
First off, I'm a bit at a loss as to how to ask this question. So I'm going to try throwing lots of information at the problem.
Ok, so, I went to completely redesign my test project for my experimental core library thingy. I use a lot of template shenanigans in the library. When I removed the "user" code, the tests gave me a memory allocation error. After quite a bit of experimenting, I narrowed it down to this bit of code (out of a couple hundred lines):
void VOODOO(components::switchBoard &board) {
board.addComponent<using_allegro::keyInputs<'w'> >();
}
Fundementally, what's weirding me out is that it appears that the act of compiling this function (and the template function it then uses, and the template functions those then use...), makes this bug not appear. This code is not being run. Similar code (the same, but for different key vals) occurs elsewhere, but is within Boost TDD code.
I realize I certainly haven't given enough information for you to solve it for me; I tried, but it more-or-less spirals into most of the code base. I think I'm most looking for "here's what the problem could be", "here's where to look", etc. There's something that's happening during compile because of this line, but I don't know enough about that step to begin looking.
Sooo, how can a (presumably) compilied, but never actually run, bit of templated code, when removed, cause another part of code to fail?
Error:
Unhandled exceptionat 0x6fe731ea (msvcr90d.dll) in Switchboard.exe:
0xC0000005: Access violation reading location 0xcdcdcdc1.
Callstack:
operator delete(void * pUser Data)
allocator< class name related to key inputs callbacks >::deallocate
vector< same class >::_Insert_n(...)
vector< " " >::insert(...)
vector<" ">::push_back(...)
It looks like maybe the vector isn't valid, because _MyFirst and similar data members are showing values of 0xcdcdcdcd in the debugger. But the vector is a member variable...
Update: The vector isn't valid because it's never made. I'm getting a channel ID value stomp, which is making me treat one type of channel as another.
Update:
Searching through with the debugger again, it appears that my method for giving each "channel" it's own, unique ID isn't giving me a unique ID:
inline static const char channel<template args>::idFunction() {
return reinterpret_cast<char>(&channel<CHANNEL_IDENTIFY>::idFunction);
};
Update2: These two are giving the same:
slaveChannel<switchboard, ALLEGRO_BITMAP*, entityInfo<ALLEGRO_BITMAP*>
slaveChannel<key<c>, char, push<char>
Sooo, having another compiled channel type changing things makes sense, because it shifts around the values of the idFunctions? But why are there two idFunctions with the same value?
you seem to be returning address of the function as a character? that looks weird. char has much smaller bit count than pointer, so it's highly possible you get same values. that could reason why changing code layout fixes/breaks your program
As a general answer (though aaa's comment alludes to this): When something like this affects whether a bug occurs, it's either because (a) you're wrong and it is being run, or (b) the way that the inclusion of that code happens to affect your code, data, and memory layout in the compiled program causes a heisenbug to change from visible to hidden.
The latter generally occurs when something involves undefined behavior. Sometimes a bogus pointer value will cause you to stomp on a bit of your code (which might or might not be important depending on the code layout), or sometimes a bogus write will stomp on a value in your data stack that might or might not be a pointer that's used later, or so forth.
As a simple example, supposing you have a stack that looks like:
float data[10];
int never_used;
int *important pointer;
And then you erroneously write
data[10] = 0;
Then, assuming that stack got allocated in linear order, you'll stomp on never_used, and the bug will be harmless. However, if you remove never_used (or change something so the compiler knows it can remove it for you -- maybe you remove a never-called function call that would use it), then it will stomp on important_pointer instead, and you'll now get a segfault when you dereference it.