41 replies to this topic

[Nyx]

So, I've been working on my LISP interpreter... I got it to compile on linux... And then... wham... segmentation fault. It works fine on windows, and I was able to trace the bug... To a bug in G++.

It seems that std::vector::resize() does NOT resize the vector. I am creating a vector of objects, and I then call resize, but its size still shows up as 0, and when I try to access the first element, I get a seg fault. I know that this is indeed a bug in G++ because it's the second time I encounter it. The last time was on a different machine, on a different project, and I had reliably traced the bug to the same cause...

Yet, as much as I know alot of people use G++, and alot of C++ programmers use std::vector, nothing shows up anywhere on google about this problem! I'm using G++ 4.0.2, and well, the newer versions don't seem to mention a patch for this in their changelogs... What the hell is going on? Can anybody with G++ on a linux machine try the vector resize function? Has anyone heard of this?

[Reedbeta]

The following compiles and gives the correct output for me, with g++ 3.3.5:

#include <iostream>
#include <vector>
using namespace std;
int main ()
{
  vector<int> vec;
  cout << "vec.size() == " << vec.size() << endl;
  vec.resize(10);
  cout << "vec.size() == " << vec.size() << endl;
  return 0;
}

The output is:

vec.size() == 0
vec.size() == 10

Maybe you could test the above program and see what result you get?

[dave_]

A common mistake is to store a reference or a pointer to an element, when you do a resize this invalidates them.
For example:

vector<int> vec;
vec.resize(10);
int &a = vec[0];
vec.resize(100);

a is undefined

[Nyx]

dave_ said:

A common mistake is to store a reference or a pointer to an element, when you do a resize this invalidates them.
For example:

vector<int> vec;

vec.resize(10);

int &a = vec[0];

vec.resize(100);

a is undefined

I'm not that newbish ;)

I actually found what the problem was. One of my classes was storing a static instance of an allocator, whose constructor initializes a pool (vector) of allocation units. But another class had another static member who required one of those units to be allocated before the constructor of the allocation pool was actually called.

[GroundKeeper]

An advice: Do not tell people how good a programmer you are unless they ask. At devmaster there are some very skilled programmers which makes the context of a good programmer very loose.

Just a friendly advice if you want to be taken serious.

[Nyx]

GroundKeeper said:

An advice: Do not tell people how good a programmer you are unless they ask. At devmaster there are some very skilled programmers which makes the context of a good programmer very loose.

Just a friendly advice if you want to be taken serious.

An advice: don't give advice unless asked for it. Looking at your recent posts, it seems you just post to post.

[bladder]

Ahh, the dreaded static ordering problem of that damned beautiful language we all have a love and hate relationship with. Nyx, What technique are using alleviate your issue? Just changed the order or you using some kind of nifty trick or something...

For anyone who's interested here's what faq lite has to say about this stuff. Several "solutions" are provided as well.

[Nyx]

bladder said:

Ahh, the dreaded static ordering problem of that damned beautiful language we all have a love and hate relationship with. Nyx, What technique are using alleviate your issue? Just changed the order or you using some kind of nifty trick or something...

For anyone who's interested here's what faq lite has to say about this stuff. Several "solutions" are provided as well.

I changed the order the object files get passed to the gcc linker and that fixed it. There seemed to be no other way to fix this problem without bastardizing my code to unacceptable levels!

[.oisyn]

As a matter of fact, your code is already bastardized because you didn't take order of initialization into account in the first place

Your fix works now, but what if you compile your code with another compiler? Or another version of the same compiler even? It's an issue that is bound to hunt you until you make a proper standard C++ fix for it

[Nyx]

.oisyn said:

As a matter of fact, your code is already bastardized because you didn't take order of initialization into account in the first place ;)

Your fix works now, but what if you compile your code with another compiler? Or another version of the same compiler even? It's an issue that is bound to hunt you until you make a proper standard C++ fix for it

Well, it works on GCC and MSVC, which is what I care about. If it doesn't work on another compiler, the people who care can make a new makefile for that other compiler. As far as I'm concerned, my code is in a state where its rather clean and easy to understand. I agree that the problem stems from the C++ standard... I don't think there should be such a thing as "undefined behavior" in a programming language... I know of at least two other cases in C++...

[.oisyn]

Actually almost every language has this problem, not just C++. And how would you standardize the order of construction? By ordering the filenames alphabetically? That's just as arbitrary as any order you can think of.

You'd better learn how to deal with this from the ground up so you won't run into these problems again

[Nyx]

.oisyn said:

Actually almost every language has this problem, not just C++. And how would you standardize the order of construction? By ordering the filenames alphabetically? That's just as arbitrary as any order you can think of.

You'd better learn how to deal with this from the ground up so you won't run into these problems again :)

Actually, any order is good enough, if you can rely on it.

[Jare]

Nyx said:

As far as I'm concerned, my code is in a state where its rather clean and easy to understand.

You swept an broken design under the rug. Your code as it stands is buggy code that just happens to work. If you try to do that in any serious programming job you'd be fired.

[Nyx]

Jare said:

You swept an broken design under the rug. Your code as it stands is buggy code that just happens to work. If you try to do that in any serious programming job you'd be fired.

ROFL.

I'd like to see you program a working, complete, extensible and stable LISP interpreter with a design half as clean as mine.

I don't see what's so bad about what I did. This problem results from a deficienty. in the C++ design, and I responded to it with a compiler-specific solution. Anyways, that statement shows you don't know much about the programming job market ;) Microsoft doesn't fire half its staff every year.

[.oisyn]

Nyx said:

Actually, any order is good enough, if you can rely on it.

You didn't quite get my point. What order would you choose, and why? And by the way, it would suit you to not be so offended by what others have to say. Clearly your design isn't as clean as you claim it to be, otherwise you wouldn't have had these problems. Jare makes a fair point. And I'm not talking about the getting fired part (which sadly enough is indeed not always true).

[Nyx]

.oisyn said:

You didn't quite get my point. What order would you choose, and why? And by the way, it would suit you to not be so offended by what others have to say. Clearly your design isn't as clean as you claim it to be, otherwise you wouldn't have had these problems. Jare makes a fair point. And I'm not talking about the getting fired part (which sadly enough is indeed not always true).

I get one bug and my design is good for the trash? Considering it's pretty much the only bug I've had, and I found a way to fix it pretty quickly, I'd say my design is pretty good.

As far as the order I would choose, I would choose the order of inclusion, or of declaration, because its the most obvious.

The only point Jare makes is that he's an arrogant and offensive <insert word of your choice>. Honestly, his comment was rather insulting, and I don't really have to prove anything about my programming skills. I don't judge your programming practices, so don't judge mine, because I've most likely been programming in C++ longer than you have, on a much higher scale than you have. Kthxbye.

As far as "sweeping a broken design under the rug goes". Let me put it this way. My original code didn't even compile on the latest microsoft compiler. And by that, I don't mean it would report programming errors, I mean I got several "fatal compiler error" messages doing it. I've had to resort to some degree of code bastardization to get Visual C++ to compile it at all. As far as I'm concerned, the compiler is broken, so don't blame me for refusing to make my code crappier.

[bladder]

The point Jare makes is that you temporarily hid a fault in your design. The fix you have is just a temporary one. When you add another object in another file that uses the static object before it's inisitalized you'll have the same problem (again). You havent fixed anything, you just hid it. That was the point.

No one said your design is good for the trash. If you can't take criticism you're going to have bigger problems then unknown static initialization order though.

[Nyx]

bladder said:

The point Jare makes is that you temporarily hid a fault in your design. The fix you have is just a temporary one. When you add another object in another file that uses the static object before it's inisitalized you'll have the same problem (again). You havent fixed anything, you just hid it. That was the point.

Well, these two classes are part of the core of the interpreter, which is very much complete. The way it's designed, there is no reason for that situation to arise again... And well, chances are, this bug will never surface again. Unless there is some huge change in GCC, which isn't likely. But it could happen? Sure it could, but then it's actually more likely some change in GCC will cause problems with some other, perfectly legit part of the code.

Quote

No one said your design is good for the trash. If you can't take criticism you're going to have bigger problems then unknown static initialization order though.

I have no problem with *constructive criticism*. I do have a problem with insults, however. I also have a problem with people who have nothing to show yet act like they know more than everyone else about everything, and people who pretend they can tell everyone else how to program. I don't criticize the fact that Jare's code is badly commented, of very poor overall quality, and that it looks like it was written by a C programmer who never fully understood C++ (I just checked his homepage!).

My point stands: I've made a thread to discuss my LISP interpreter a while ago, and none of you commented on any aspect of the product itself. You're only here now, to post negative criticism about a bug that's been solved over two weeks ago. Not because you want to help, but because you feel the need to believe you're better than someone else at something. Honestly... I'm sure people tell me I should be fired because they have a very strong altruistic need to help others a là mother Teresa.

Since this thread is going nowhere fast, I suggest locking it.

[.oisyn]

Nyx said:

As far as the order I would choose, I would choose the order of inclusion, or of declaration, because its the most obvious.

You don't include source files, and order of construction within a sourcefile is very well-defined. When working with static constructor code (e.g., all code that get's executed before main()), you have to make sure everything's constructed in the right order. So create accessors for your global variables (you shouldn't use global variables anyway) so you can ensure construction order. And this goes for ANY imperative language, not just C++.

Quote

The only point Jare makes is that he's an arrogant and offensive <insert word of your choice>.

No, you just don't seem to be able to take any form of critisism. It shows from almost every reply in your thread. And quite frankly, that makes YOU the arrogant person, not others.

Quote

Honestly, his comment was rather insulting, and I don't really have to prove anything about my programming skills.

No you don't, and nobody's asking you to. But you seem to think that you do.

Quote

because I've most likely been programming in C++ longer than you have, on a much higher scale than you have. Kthxbye.

Another typical arrogant remark. Btw, experience alone doesn't make you a good programmer. DISCLAIMER: I'm not saying that you are a lousy programmer (somehow I think this disclaimer is a necessary, given your earlier reactions), I'm just saying that "I've been coding way longer than you are" is just not a good argument.

However, the fact that you didn't knew this bug could happen and that you didn't take that into account in your design, and by the way you solved it, I can't help to wonder how good a programmer you really are, or how much so called experience you're actually having with C++. You just keep rambling about how it's C++'s fault. No, it's not the language's fault, it's your fault.

Quote

As far as "sweeping a broken design under the rug goes". Let me put it this way. My original code didn't even compile on the latest microsoft compiler. And by that, I don't mean it would report programming errors, I mean I got several "fatal compiler error" messages doing it. I've had to resort to some degree of code bastardization to get Visual C++ to compile it at all. As far as I'm concerned, the compiler is broken, so don't blame me for refusing to make my code crappier.

I'm sorry but this simply has got nothing to do with the problem you where having. Don't make arguments that have no relevance to the discussion.

[eddie]

I'm side-stepping the whole arrogant/criticism thing here, so pardon me for poking my head in.

Nyx, you may already be aware of this, but if you want to get a 'set' order of initialization, try using a singleton pattern. If you end up doing this for your static accesses to global data, you'll ensure that something is appropriately set the first time through.

That said, I'm not sure if that will help, since there's no code provided, but reading the discussion this sounds like it might help.