Some strange error

D

david

I took old code and decided to modify it a bit, and I just noticed
that it does not compile at all and before server one of severs (main)
crashed in the system it was working fine (I am really sure that I
remember that).

Now I am getting this error:
[me@smth kazkas]$ make
g++ -Wall -ansi -pedantic -c pirma_lib.cpp
g++ -Wall -ansi -pedantic -c pirma.cpp
In file included from pirma.cpp:2:
pirma_lib.h:13: syntax error before `('
pirma.cpp: In function `int main(int, const char **)':
pirma.cpp:68: no matching function for call to `Aibe::toString ()'
pirma.cpp:126: no matching function for call to `Aibe::toString ()'
*** Error code 1

Stop in /somewhere.

The main problem should be right here:
pirma_lib.h:13: syntax error before `('

So here it is:
#ifndef PIRMA_LIB
#define PIRMA_LIB

class Aibe {
public:
Aibe();
Aibe(int arr[], int length);
Aibe(int item, ...);
~Aibe();

bool isSubSet(const Aibe &other) const;
void toArray(int **arr) const;
std::string toString() const; //
<--------------
int length() const;
//void Sort();

Any ideas why I can not compile it anymore? Could something be wrong
with std?
 
J

Jim Langston

david said:
I took old code and decided to modify it a bit, and I just noticed
that it does not compile at all and before server one of severs (main)
crashed in the system it was working fine (I am really sure that I
remember that).

Now I am getting this error:
[me@smth kazkas]$ make
g++ -Wall -ansi -pedantic -c pirma_lib.cpp
g++ -Wall -ansi -pedantic -c pirma.cpp
In file included from pirma.cpp:2:
pirma_lib.h:13: syntax error before `('
pirma.cpp: In function `int main(int, const char **)':
pirma.cpp:68: no matching function for call to `Aibe::toString ()'
pirma.cpp:126: no matching function for call to `Aibe::toString ()'
*** Error code 1

Stop in /somewhere.

The main problem should be right here:
pirma_lib.h:13: syntax error before `('

So here it is:
#ifndef PIRMA_LIB
#define PIRMA_LIB

class Aibe {
public:
Aibe();
Aibe(int arr[], int length);
Aibe(int item, ...);
~Aibe();

bool isSubSet(const Aibe &other) const;
void toArray(int **arr) const;
std::string toString() const; //
<--------------
int length() const;
//void Sort();

Any ideas why I can not compile it anymore? Could something be wrong
with std?

#include <string>
 
D

david

No, string.h has nothing to do in this situation and I am not using
any C style strings.
And I just tested the same code on my MacBook and it did work
perfectly.
While on server (FreeBSD 4.11-RELEASE-p11) with 2.95.4 it does not
work anymore...
 
J

Jim Langston

david said:
No, string.h has nothing to do in this situation and I am not using
any C style strings.
And I just tested the same code on my MacBook and it did work
perfectly.
While on server (FreeBSD 4.11-RELEASE-p11) with 2.95.4 it does not
work anymore...

In the code you provided you have the line:

std::string toString() const;

I did not see
#include <string>
in the code you provided. When you add
#include <string>
to the top of that header and compile do you still get the error?

And I did not say string.h but <string> <string> is std::string, which you
are using in this code. string.h is c-style strings.
 
D

david

Now I always gettting a lot of lines:
pirma in free(): warning: chunk is already free
Even after commenting the whole destructor, which uses free...
Something strange... It did work very fine before...
 
I

Ian Collins

david said:
Now I always gettting a lot of lines:
pirma in free(): warning: chunk is already free
Even after commenting the whole destructor, which uses free...
Something strange... It did work very fine before...

Who or what are you replying to? This does not make sense.
 
J

Jim Langston

Ian said:
Who or what are you replying to? This does not make sense.

he is replying to me. He is stating that with
#include <string>
his code now compiles, but produces run time error.

David, you have not shown enough code for us to determine where this run
time error would be coming from. You either need to show more code, or use
a debugger.
 
D

david

It's still very strange... Tested the same code again inside on one of
the Linux machine (Debian) and code compiled very nicely, zero errors/
warning and etc, no run time errors.

Doing the same on FreeBSD machine it produces run time error, program
is compiled into "pirma", and after execution it works as it should be
and after some time it throws multiple lines of "pirma in free():
warning: chunk is already free" and some parts of program works
completely wrong.

And I don't use free() in any part of code. I still think that
compiler/some libraries in this machine might be broken and the error
could be produced no in my code. The code is too simply and it runs on
other machines.
 
I

Ian Collins

david said:
It's still very strange... Tested the same code again inside on one of
the Linux machine (Debian) and code compiled very nicely, zero errors/
warning and etc, no run time errors.
What code?
 
J

Jim Langston

david said:
It's still very strange... Tested the same code again inside on one of
the Linux machine (Debian) and code compiled very nicely, zero errors/
warning and etc, no run time errors.

Doing the same on FreeBSD machine it produces run time error, program
is compiled into "pirma", and after execution it works as it should be
and after some time it throws multiple lines of "pirma in free():
warning: chunk is already free" and some parts of program works
completely wrong.

And I don't use free() in any part of code. I still think that
compiler/some libraries in this machine might be broken and the error
could be produced no in my code. The code is too simply and it runs on
other machines.

You are probably running into undefined behavior. Undefined behavior means
that the standard doesn't define what will happen in some situations. For
example: the following is undefined behavior:

char* foo;
delete foo;

foo wasn't initilialized, it could point to anything. It might point to
address 0 so would be a null pointer, or some compilers might point it to
some random spot in memory or.. anywhere. So the delete foo could do
differnet things on differnet compilers. It's undefined.

So your code could have undefined behavior that works one way on Debian, one
way on FreeBSD. I would suggest you create the smallest compilable program
that will produces this behavior on FreeBSD and post here it.
 
D

david

I will try that a bit later, one more thing I am using the same exact
version of compiler and I get those run time errors only on that
machine and it even did work before. So even "undefined behavior" here
sound very strange, because that would depend on the compiler which is
the same.
 
D

david

Here is what I get:
ccc + ddd : 1
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
ddd + ccc : 1
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
ddd + fff : 1
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
pirma in free(): warning: chunk is already free
fff + ddd : 1

So it would look that problem would be with dynamic memory and
assignment operator (maybe not) or something wrong with other
operations.
// from array
int arr[5] = {1, 2, 3, 4, 5};
Aibe ccc(arr, 5);

// from parameters
Aibe ddd(7, 1,2,3,4,5,6,7);
Aibe xxx;
xxx = ccc + ddd;
cout << "ccc + ddd : " << xxx << endl;
xxx = ddd + ccc;
cout << "ddd + ccc : " << xxx << endl;
xxx = ddd + fff;
cout << "ddd + fff : " << xxx << endl;
xxx = fff + ddd;
cout << "fff + ddd : " << xxx << endl;

I still will try to catch where is the problem...
 
D

david

Found which part of code throw that warning:
void Aibe::innerDestructor(Aibe &other) {
child *tmp;
while (other.root != NULL)
{
tmp = other.root;
other.root = tmp->next;
delete(tmp); // <- THIS LINE
}
other.root = NULL;
other.size = 0;
}
 
D

david

I did spend some time trying to reproduce the same warning in new
code, but I could not find how even after I wrote almost the same
code. I feel a bit lost here...

Files:
http://www.paste.lt/paste/795d5e429a61d2d7869c930d528c90a8 -
pirma_lib.h
http://www.paste.lt/paste/81bdbd4efcb450bb10f25464ef667f00 -
pirma_lib.cpp

Test file (pirma.cpp):
#include <iostream>
#include "pirma_lib.h"

using namespace std;

int main (int argc, char const *argv[])
{
// from array
int arr[5] = {1, 2, 3, 4, 5};
Aibe ccc(arr, 5);

// from parameters
Aibe ddd(7, 1,2,3,4,5,6,7);

// from parameters
Aibe fff(7, 2,2,3,4,5,6,7);

Aibe xxx;

xxx = ccc + ddd;
cout << "ccc + ddd : " << xxx << endl;
xxx = ddd + ccc;
cout << "ddd + ccc : " << xxx << endl;
xxx = ddd + fff;
cout << "ddd + fff : " << xxx << endl;
xxx = fff + ddd;
cout << "fff + ddd : " << xxx << endl;

cout << endl;

return 0;
}

I even took the compiled version of the program from other machine (of
course it works in that machine) and again it did not work as it
should be in this UNIX machine. Any ideas?
 
J

Jim Langston

david said:
Found which part of code throw that warning:
void Aibe::innerDestructor(Aibe &other) {
child *tmp;
while (other.root != NULL)
{
tmp = other.root;
other.root = tmp->next;
delete(tmp); // <- THIS LINE
}
other.root = NULL;
other.size = 0;
}

Okay, this looks like a recursive destructor, but it depends on child's
destructor. I'm guessing that child's destructor also deletes .root or some
some deleting.

Can you post child's destructor here please?
 
J

Jim Langston

david said:
I did spend some time trying to reproduce the same warning in new
code, but I could not find how even after I wrote almost the same
code. I feel a bit lost here...

Files:
http://www.paste.lt/paste/795d5e429a61d2d7869c930d528c90a8 -
pirma_lib.h
http://www.paste.lt/paste/81bdbd4efcb450bb10f25464ef667f00 -
pirma_lib.cpp

Test file (pirma.cpp):
#include <iostream>
#include "pirma_lib.h"

using namespace std;

int main (int argc, char const *argv[])
{
// from array
int arr[5] = {1, 2, 3, 4, 5};
Aibe ccc(arr, 5);

// from parameters
Aibe ddd(7, 1,2,3,4,5,6,7);

// from parameters
Aibe fff(7, 2,2,3,4,5,6,7);

Aibe xxx;

xxx = ccc + ddd;
cout << "ccc + ddd : " << xxx << endl;
xxx = ddd + ccc;
cout << "ddd + ccc : " << xxx << endl;
xxx = ddd + fff;
cout << "ddd + fff : " << xxx << endl;
xxx = fff + ddd;
cout << "fff + ddd : " << xxx << endl;

cout << endl;

return 0;
}

I even took the compiled version of the program from other machine (of
course it works in that machine) and again it did not work as it
should be in this UNIX machine. Any ideas?

Look at my previous post. My suspition is that you are deleting the same
pointer twice, which is undefined behavior.

One way I've found this weird type of bug before is search for "delete" in
my code, and before the delete do something like:
std::cout << "Deleting pointer " << /* some way to distinguish this instance
from others */
this usually shows me right where I"m deleting it twice.
 
D

david

Here is the info:
http://www.paste.lt/paste/3ca55040e2edbe3730e8c0ce6067d6e5

And this is the only destructor which frees the list from the heap.
When I was making this test I commented the line where InnerDestructor
is called (not a good idea) and as you can see it still produces this
mess. I even set up BSD in one of my machines at home, running g++
3.4.6 which does not have any problems. Looks like this only effects
old versions of compilers.

I still can't get this:ccc + ddd : 1

First of all it launches destructor of the ddd which has 7 elements
(1,2,..,7) inside and when one more for I don't know there is no
instance of that class with only one element. So ddd becomes empty and
ccc has 1 element (but had five elements) and {1} + {} = {1}; Why does
it call destructor when no one asks to do that? Was that how it was
designed few years ago?
 
D

david

Found something even more interesting:

Some time spent with a debugger and searching for reports of similar
error messages (and drawing on my own experience developing
software :)
leads me to feel that the junk pointer error message is a symptom of
library ABI incompatibility. First of all, the message is from the
system
call to free in libc; this is not a Qt problem. Since libc was built
using the compiler provided by the system (FreeBSD 4.cool it uses the
gcc
2.95.4 ABI. However, I have upgraded to gcc 3.3.1 for my development
work. The ABI went through significant changes across this major rev.
I've had to recompile several libraries to overcome the differences.
So even
though this problem does not always occur (I have not dug deep enough
to
identify the specific cause for free getting upset), and does not
occur
with the other C++ libraries I have developed, I now think that the
system libraries (including the X11 libraries) need to be brought
across
the ABI divide.

And here:
http://osdir.com/ml/hardware.gps.gpsbabel.devel/2005-07/msg00000.html
 
I

Ian Collins

david said:
Found something even more interesting:

Some time spent with a debugger and searching for reports of similar
error messages (and drawing on my own experience developing
software :)
leads me to feel that the junk pointer error message is a symptom of
library ABI incompatibility.

Your code has a number of memory related nasties, which were too
involved for a casual scan. Run your code under whatever memory access
checker your platform provides and you will find them.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,228
Members
46,818
Latest member
SapanaCarpetStudio

Latest Threads

Top