Some strange error

[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?

[Jim Langston]

david wrote:

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>

--
Jim Langston
ta*******@rocketmail.com

[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...

[Jim Langston]

david wrote:

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 <stringis std::string, which you
are using in this code. string.h is c-style strings.


--
Jim Langston
ta*******@rocketmail.com

[david]

Yes, not it did compile but I am getting some error on run time.

[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...

[Ian Collins]

david wrote:

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.

--
Ian Collins.

[Jim Langston]

Ian Collins wrote:

david wrote:

>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.

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.

--
Jim Langston
ta*******@rocketmail.com

[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.

[Ian Collins]

david wrote:

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?

--
Ian Collins.

[Jim Langston]

david wrote:

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.


--
Jim Langston
ta*******@rocketmail.com

[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.

[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;
}

[Jim Langston]

david wrote:

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?

--
Jim Langston
ta*******@rocketmail.com

[david]

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

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:

>Starting to delete (0xbfbff8d8)
Deleted item: 1
Deleted item: 2
Deleted item: 3
Deleted item: 4
Deleted item: 5
Deleted item: 6
Deleted item: 7
Starting to delete (0xbfbff954)
Deleted item: 1

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?

[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.gps.../msg00000.html

[Ian Collins]

david wrote:

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.

--
Ian Collins.

[Jim Langston]

Ian Collins wrote:

david wrote:

>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.

Someone has suggested valgrind. I've never used it myelf, but it seems to
be opensource. I would suggest you go to http://valgrind.org/ and download
it and give it a try. Maybe it'll help.

--
Jim Langston
ta*******@rocketmail.com

[david]

I my case it should not, in assignment operator not. First of all I
free all elements from the left side variable (maybe it would better
to call it lvalue?) and then make exact copy of the right variable.
Basically it works as a copy constructor.

[James Kanze]

On May 2, 12:48 pm, david <[e-mail]:

I my case it should not, in assignment operator not. First of all I
free all elements from the left side variable (maybe it would better
to call it lvalue?) and then make exact copy of the right variable.
Basically it works as a copy constructor.

I'm not sure what you're responding to (that "should not"), but
your suggestion as to how to implement an assignment operator
won't work. Think of what will happen if something in the copy
throws.

For classes with pointers to dynamically allocated data, the
swap idiom is simple, and almost always appropriate; if the
class has more than one such pointer, it's really the way to go,
no questions asked. Whatever you do, however, it's generally a
good idea to do anything which can possibly throw before
modifying any member variables; failing that, at least make sure
that calling the destructor will never result in undefined
behavior.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]