Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #5308 > unrolled thread

gcc bug?

Back to article view | Back to comp.lang.c++

Contents

  gcc bug? Ruben Safir <ruben@mrbrklyn.com> - 2011-05-22 01:32 +0000
    Re: gcc bug? "Balog Pal" <pasa@lib.hu> - 2011-05-22 04:34 +0200
      Re: gcc bug? Ruben Safir <ruben@mrbrklyn.com> - 2011-05-22 04:13 +0000
        Re: gcc bug? Ian Collins <ian-news@hotmail.com> - 2011-05-22 16:16 +1200
      Re: gcc bug? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 07:08 +0000
        Re: gcc bug? Ruben Safir <ruben@mrbrklyn.com> - 2011-05-22 11:35 +0000
          Re: gcc bug? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 13:00 +0000
            Re: gcc bug? Ruben Safir <ruben@mrbrklyn.com> - 2011-05-22 14:27 +0000

#5308 — gcc bug?

I've been working with gcc 4.6 with C++ doing some templates exercises

I seem to have some unexplained behavior which might be a bug, or maybe
I'm ignorant.

First - let me give you a link for my code

http://www.nylxs.com/docs/linklist.tgz


specifically, I wrote a program to test my templates that create a linked
list class. There is a simple library to do some statistics on the list
members. It is doing a double delete core dump in a section of code that
I see no reason for a destructor call. It didn't do this for a simpler
version of the template argument call.

ddd ./test_del2
test_del2.cpp:84

79 for( i=0; i < 100; ++i){
80 std::cout << "index " << i << "-------------------------------
\n";
81 tally = new chainlist::List<stats::Distribution<int> >;
82 stats::take_tally<int>(a[i], tally );
83 std::cout << "Creating Tally " << std::endl;
84 tallies->insert(*tally);
85 std::cout << "inserted population figures for index " << i <<
"-------------------------------\n";
86 delete tally;
87
88 //visual inspection of population data to make sure the resiults work
89 // std::cout << "visual inspection of population data to make sure the results work" << std::endl;

breaking on line 84 and the stepping through

263 void List<T>::insert ( T val )
264 {
265 if(!front()){
266 Node<T> * tmp = new Node<T>(val);
267 front(tmp);
268 endd(tmp);
269 cursor(tmp);
270 sizeup();
271 return;
272 }else{
273 Node<T> * tmp = new Node<T>(val, endd());
274 // endd()->next(tmp); // redundant
275 endd(tmp);
276 cursor(tmp);
277 sizeup();
278 return;
279 }
280 } /* --- end of method List<T>::insert ----

/home/ruben/cplus/link_list_template_mysql/linklist.h:265
is the next line

on line 266 is where it seems to be doing weird stuff

home/ruben/cplus/link_list_template_mysql/linklist.h:266

it calls the correct constructor for the node object
/home/ruben/cplus/link_list_template_mysql/linklist.h:82
81 Node<unk>::Node(unk val, Node<unk> *item_to_link_to){
82 value(val);
83 if(!item_to_link_to){
84 next_ = 0;
85 }
86
87 else{
88 next(item_to_link_to->next());
89 item_to_link_to->next(this);
90 }
91 }

I the calls the accessory method value() from the list class

108 }
109
110 template<class unk>
111 void Node<unk>::value(unk val){
112 value_ = new unk(val);
113 }
114
/home/ruben/cplus/link_list_template_mysql/linklist.h:112

it returns nomally

81 Node<unk>::Node(unk val, Node<unk> *item_to_link_to){
82 value(val);
83 if(!item_to_link_to){
84 next_ = 0;
85 }
86
87 else{
88 next(item_to_link_to->next());
89 item_to_link_to->next(this);
90 }
91 }
92 chainlist::Node<chainlist::List<stats::Distribution<int> > >::Node (this=0x809f488, val=..., item_to_link_to=0x0) at /home/ruben/cplus/link_list_template_mysql/linklist.h:83


then it calls for the List destructor, I have no idea way

373 template<class T>
374 List<T>::~List<T>(){
375 remove_all();
376 // std::cout << "Deleted All*************" << __LINE__ << std::endl;
377 }
378
(gdb) ptype List
Type chainlist::List<stats::Distribution<int> > has no component named List.
(gdb) *** glibc detected *** /home/ruben/cplus/link_list_template_mysql/test_del2: double free or corruption (out): 0x0809f460 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7d9150b]
/lib/libc.so.6[0xb7d92de4]
/lib/libc.so.6(cfree+0x6d)[0xb7d95fdd]
/usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb7f7c87f]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804b4a4]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804b2c6]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804aa30]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804987d]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x80498f0]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x8048d42]
/lib/libc.so.6(__libc_start_main+0xfe)[0xb7d3aace]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x8048961]
======= Memory map: ========
08048000-0804d000 r-xp 00000000 08:12 270203586 /home/ruben/cplus/link_list_template_mysql/test_del2
0804d000-0804e000 r--p 00004000 08:12 270203586 /home/ruben/cplus/link_list_template_mysql/test_del2
0804e000-0804f000 rw-p 00005000 08:12 270203586 /home/ruben/cplus/link_list_template_mysql/test_del2
0804f000-080b2000 rw-p 00000000 00:00 0 [heap]
b7c00000-b7c21000 rw-p 00000000 00:00 0
b7c21000-b7d00000 ---p 00000000 00:00 0
b7d22000-b7d24000 rw-p 00000000 00:00 0
b7d24000-b7e7d000 r-xp 00000000 08:02 36311 /lib/libc-2.10.1.so
b7e7d000-b7e7e000 ---p 00159000 08:02 36311 /lib/libc-2.10.1.so
b7e7e000-b7e80000 r--p 00159000 08:02 36311 /lib/libc-2.10.1.so
b7e80000-b7e81000 rw-p 0015b000 08:02 36311 /lib/libc-2.10.1.so
b7e81000-b7e84000 rw-p 00000000 00:00 0
b7e84000-b7ea0000 r-xp 00000000 08:02 910019 /lib/libgcc_s.so.1
b7ea0000-b7ea1000 r--p 0001b000 08:02 910019 /lib/libgcc_s.so.1
b7ea1000-b7ea2000 rw-p 0001c000 08:02 910019 /lib/libgcc_s.so.1
b7ea2000-b7ec9000 r-xp 00000000 08:02 36319 /lib/libm-2.10.1.so
b7ec9000-b7eca000 r--p 00027000 08:02 36319 /lib/libm-2.10.1.so
b7eca000-b7ecb000 rw-p 00028000 08:02 36319 /lib/libm-2.10.1.so
b7ecb000-b7faf000 r-xp 00000000 08:02 348377 /usr/lib/libstdc++.so.6.0.16
b7faf000-b7fb3000 r--p 000e3000 08:02 348377 /usr/lib/libstdc++.so.6.0.16
b7fb3000-b7fb4000 rw-p 000e7000 08:02 348377 /usr/lib/libstdc++.so.6.0.16
b7fb4000-b7fbb000 rw-p 00000000 00:00 0
b7fde000-b7fe0000 rw-p 00000000 00:00 0
b7fe0000-b7ffe000 r-xp 00000000 08:02 36304 /lib/ld-2.10.1.so
b7ffe000-b7fff000 r--p 0001d000 08:02 36304 /lib/ld-2.10.1.so
b7fff000-b8000000 rw-p 0001e000 08:02 36304 /lib/ld-2.10.1.so
bffeb000-c0000000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

Program received signal SIGABRT, Aborted.
0xffffe430 in __kernel_vsyscall ()
(gdb) delete 7
(gdb)


I've rattled my brain on this and can't explain it 

[toc] | [next] | [standalone]

#5309

"Ruben Safir" <ruben@mrbrklyn.com>
> I've been working with gcc 4.6 with C++ doing some templates exercises
>
> I seem to have some unexplained behavior which might be a bug, or maybe
> I'm ignorant.

maybe. first run your code in valgrind and look if it points out the 
corruption.

[toc] | [prev] | [next] | [standalone]

#5311

On Sun, 22 May 2011 04:34:36 +0200, Balog Pal wrote:

> "Ruben Safir" <ruben@mrbrklyn.com>
>> I've been working with gcc 4.6 with C++ doing some templates exercises
>>
>> I seem to have some unexplained behavior which might be a bug, or maybe
>> I'm ignorant.
> 
> maybe. first run your code in valgrind and look if it points out the
> corruption.

valgrind?

[toc] | [prev] | [next] | [standalone]

#5312

On 05/22/11 04:13 PM, Ruben Safir wrote:
> On Sun, 22 May 2011 04:34:36 +0200, Balog Pal wrote:
>
>> "Ruben Safir"<ruben@mrbrklyn.com>
>>> I've been working with gcc 4.6 with C++ doing some templates exercises
>>>
>>> I seem to have some unexplained behavior which might be a bug, or maybe
>>> I'm ignorant.
>>
>> maybe. first run your code in valgrind and look if it points out the
>> corruption.
>
> valgrind?

google.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5321

On Sun, 2011-05-22, Balog Pal wrote:
> "Ruben Safir" <ruben@mrbrklyn.com>
>> I've been working with gcc 4.6 with C++ doing some templates exercises
>>
>> I seem to have some unexplained behavior which might be a bug, or maybe
>> I'm ignorant.
>
> maybe. first run your code in valgrind and look if it points out the 
> corruption.

I get "75060 errors from 34 contexts" when I run the "del2" test, and
they start appearing long before the crash.  Most seem to be about
accessing freed memory. I see no reason to suspect a compiler bug. (I
used gcc 4.4; there is no use of experimental C++0x features in the
code.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#5329

On Sun, 22 May 2011 07:08:35 +0000, Jorgen Grahn wrote:

> On Sun, 2011-05-22, Balog Pal wrote:
>> "Ruben Safir" <ruben@mrbrklyn.com>
>>> I've been working with gcc 4.6 with C++ doing some templates exercises
>>>
>>> I seem to have some unexplained behavior which might be a bug, or
>>> maybe I'm ignorant.
>>
>> maybe. first run your code in valgrind and look if it points out the
>> corruption.
> 
> I get "75060 errors from 34 contexts" when I run the "del2" test, and
> they start appearing long before the crash.  Most seem to be about
> accessing freed memory. I see no reason to suspect a compiler bug. (I
> used gcc 4.4; there is no use of experimental C++0x features in the
> code.)
> 
> /Jorgen

ruben@www2:~/cplus/link_list_template_mysql> g++ -Wall -ggdb test_del2.cpp -o test_del2
ruben@www2:~/cplus/link_list_template_mysql> 

compiles cleanly

I'm seeing a behavior I never saw before, though in the template

I have this class method in the template

   template < class T >
      void List<T>::find_value(T val)
      {
	 cursor() = front();
	 while(cursor() != endd()){
	    if (*(cursor()->value()) == val)
	       return;
	    else{
	       cursor(cursor()->next());
	    }
	 }
	 if(*(endd()->value()) == val)
	    return;
	 else{
	    cursor() = 0; //park the cursor when nothing is found
	 }
      }


I'm calling it from this snippit of code



   template<typename T>
      float mean_list(chainlist::List< chainlist::List<stats::Distribution<T> >*  > *  tallies, T search_val){
	 if(tallies->endd() == 0){
	    std::cout << "Empty List" << std::endl;
	    return 0.0;
	 }
	 int sum = 0;
	 chainlist::List<stats::Distribution<T> > * dump;
	 tallies->cursor() = tallies->front();
	 while(tallies->cursor() != tallies->endd() ){
		 //tallies->cursor()->value()->find_value(search_val);
		 dump = *(tallies->cursor()->value());
		 dump->find_value(search_val);
		 sum +=  dump->cursor()->value()->population();
	 }
	 dump = *(tallies->cursor()->value());
	 dump->find_value(search_val);
	 sum +=  dump->cursor()->value()->population();
	 return sum/(tallies->size());

      }

that makes dump according to gdb a type of

(gdb) ptype dump
type = class chainlist::List<stats::Distribution<int> > 

with a public member function 
void find_value(stats::Distribution<int>);

all of which I expected.  What I don't expect is that when I call from main

 std::cout << "The standard mean for picking 7 is ==> " << stats::mean_list(tallies, 7 );

then T has to be defined as a integer, and the param 7 is being promoted and calling the Distribution object constructor.

.
Ruben

[toc] | [prev] | [next] | [standalone]

#5336

On Sun, 2011-05-22, Ruben Safir wrote:
> On Sun, 22 May 2011 07:08:35 +0000, Jorgen Grahn wrote:
>
>> On Sun, 2011-05-22, Balog Pal wrote:
>>> "Ruben Safir" <ruben@mrbrklyn.com>
>>>> I've been working with gcc 4.6 with C++ doing some templates exercises
>>>>
>>>> I seem to have some unexplained behavior which might be a bug, or
>>>> maybe I'm ignorant.
>>>
>>> maybe. first run your code in valgrind and look if it points out the
>>> corruption.
>> 
>> I get "75060 errors from 34 contexts" when I run the "del2" test, and
>> they start appearing long before the crash.  Most seem to be about
>> accessing freed memory. I see no reason to suspect a compiler bug. (I
>> used gcc 4.4; there is no use of experimental C++0x features in the
>> code.)
>> 
>> /Jorgen
>
> ruben@www2:~/cplus/link_list_template_mysql> g++ -Wall -ggdb test_del2.cpp -o test_del2
> ruben@www2:~/cplus/link_list_template_mysql> 
>
> compiles cleanly

You forgot -ansi -Wextra -pedantic -O3, but it still compiles cleanly
after that.

> I'm seeing a behavior I never saw before, though in the template
...
> that makes dump according to gdb a type of
...

Do yourself a favor and follow BP's advice: install and use valgrind.
You seem to be on a system where it's supported.  Like I wrote above,
it will show errors a /long/ time before the crash.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#5339

On Sun, 22 May 2011 13:00:00 +0000, Jorgen Grahn wrote:

> valgrind

seems to be on the system already.  Thanks fir the tip.  I have found one 
definite problem with the delete of a List object, and two issues that 
confuse me with regard to how the template params are workin

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web