Including <iostream> affects whether or not program freezes?

Including <iostream> affects whether or not program freezes?

[James Gregory]

1. Compile with MSVC 7.1, no optimization: my program doesn't freeze
2. Compile with MSVC 7.1, with optimization: my program doesn't freeze
3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
doesn't freeze
4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
program freezes in a particular function
5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and
include <iostream> at the top of the file where the function which
freezes is defined: my program doesn't freeze

Debugging this is difficult.

James

Re: Including <iostream> affects whether or not program freezes?

[Lionel B]

On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote:

> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2.
> Compile with MSVC 7.1, with optimization: my program doesn't freeze 3.
> Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
> doesn't freeze
> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program
> freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64
> bit), with optimization, and include <iostream> at the top of the file
> where the function which freezes is defined: my program doesn't freeze

You give *way* too little information to even begin to guess what the 
problem might be... but this smells like a classic case of Undefined 
Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you 
have a bug in your program.

> Debugging this is difficult.

It frequently is ;-) but what other choice do you have? There are tools 
to help (debuggers such as gdb, memory leak checkers such as 
valgrind, ...)

First I would try stripping your program down to a minimal core that 
exhibits the buggy behaviour. Often in doing so you will isolate and 
identify the bug. If not seek help here or in a C (or C++, you don't say 
which language your program is in) forum. You can post minimal code 
demonstrating the problem.

-- 
Lionel B

Re: Including <iostream> affects whether or not program freezes?

[Andrew Bell]

On Tue, Jul 8, 2008 at 9:31 PM, James Gregory <james.jrg@gmail.com> wrote:
>
> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
> program freezes in a particular function

Kill the process with some signal that will generate a core.  This at
least gives you a exact location of the hang, if you don't already
know it.

-- 
Andrew Bell
andrew.bell.ia@gmail.com

Re: Including <iostream> affects whether or not program freezes?

[Andrew Haley]

Andrew Bell wrote:
> On Tue, Jul 8, 2008 at 9:31 PM, James Gregory <james.jrg@gmail.com> wrote:
>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
>> program freezes in a particular function
> 
> Kill the process with some signal that will generate a core.  This at
> least gives you a exact location of the hang, if you don't already
> know it.

I'll use this opportunity to mention Valgrind's memory checker.

Andrew.

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Wed, Jul 9, 2008 at 12:28 PM, Lionel B <lionelb.nospam@gmail.com> wrote:
> On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote:
>
>> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2.
>> Compile with MSVC 7.1, with optimization: my program doesn't freeze 3.
>> Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
>> doesn't freeze
>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program
>> freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64
>> bit), with optimization, and include <iostream> at the top of the file
>> where the function which freezes is defined: my program doesn't freeze
>
> You give *way* too little information to even begin to guess what the
> problem might be... but this smells like a classic case of Undefined
> Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you
> have a bug in your program.

Sure, I agree it is 99.999999% certain I am doing something wrong
hence the undefined behaviour. But doesn't it seem somewhat out of the
ordinary that the behaviour can be affected by which standard library
header files I include? How can this make a difference to the code
that gcc produces? It seems unlikely that it's a total coincidence
that whenever I run the version with iostream included it doesn't
freeze and whenever I run the version without it does (I just tried
recompiling the two versions again and the pattern holds).

>
>> Debugging this is difficult.
>
> It frequently is ;-) but what other choice do you have? There are tools
> to help (debuggers such as gdb, memory leak checkers such as
> valgrind, ...)

I have used gdb to see which function it freezes in, but as noted I
cannot compile with full debugging symbols and watch variables/step
through the code as this removes the bug. valgrind doesn't report any
problems at all (except a few warnings about functions called in
external libraries at start up). The reason I originally wanted to
include iostream was an effort to output the value of variables at
various points in the function which freezes, but as noted this also
removes the bug.

>
> First I would try stripping your program down to a minimal core that
> exhibits the buggy behaviour. Often in doing so you will isolate and
> identify the bug. If not seek help here or in a C (or C++, you don't say
> which language your program is in) forum. You can post minimal code
> demonstrating the problem.

But if even including a certain header file can affect the behaviour,
how can I strip down the program except through random trial and
error? I guess what I'm trying to say is not "What is wrong with my
program?", when clearly I haven't given enough information for anyone
to help, but rather "Does anyone know what sort of thing might be
affected in the code gcc produces if I include iostream is included?".

(And it is C++ not C, hence <iostream>)

James

Re: Including <iostream> affects whether or not program freezes?

[Chris Jefferson]

2008/7/9 James Gregory <james.jrg@gmail.com>:
> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze
> 2. Compile with MSVC 7.1, with optimization: my program doesn't freeze
> 3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
> doesn't freeze
> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
> program freezes in a particular function
> 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and
> include <iostream> at the top of the file where the function which
> freezes is defined: my program doesn't freeze
>
> Debugging this is difficult.

While I could well be repeating what others say, my usual tools for
situations like this, which (touch wood) tend to get me out of it:

A) Turn on all warnings, and read what they say. I've found this kind
of thing can be caused by a missing return statement.
B) Turn on the debugging standard library, if you are using any of the
STL in your code.
C) Find the minimial set of optimisation flags you need to trigger
your problem (in particular if you can turn off inlining it will make
things easier). This makes the next stage easier.
D) Use valgrind and see what it comes up with.

The <iostream> problem sounds to me like your problem could well be
triggered by inlining, which is often very sensitive (at least in g++)
and can change from headers being included on occasion.


>
> James
>

Re: Including <iostream> affects whether or not program freezes?

[Burlen Loring]

Hi James,

Including a header can affect the program somewhat.variables for 
instance might be placed in a different physical location due to 
slightly different executable size or optimization packing/aligning. 
This is the type of thing that you can see with using uninitialized 
variables. Also if you are running off the end of an array that was 
allocated on the stack(valgrind doesn't catch this as far as I know), 
you can see changes in behavior that come about with variations in the 
compile, because optimization sometimes packs and aligns data so that it 
ends up in a different spot relative to unoptimized build. With 
different memory used different bytes get trashed and hence the run time 
variability. Its often repeatable due to the fact that once the program 
runs it's likely to get loaded into the same physical memory each time 
it runs.

Burlen

James Gregory wrote:
> On Wed, Jul 9, 2008 at 12:28 PM, Lionel B <lionelb.nospam@gmail.com> wrote:
>   
>> On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote:
>>
>>     
>>> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze 2.
>>> Compile with MSVC 7.1, with optimization: my program doesn't freeze 3.
>>> Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
>>> doesn't freeze
>>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my program
>>> freezes in a particular function 5. Compile with gcc 4.2.3 (Ubuntu 64
>>> bit), with optimization, and include <iostream> at the top of the file
>>> where the function which freezes is defined: my program doesn't freeze
>>>       
>> You give *way* too little information to even begin to guess what the
>> problem might be... but this smells like a classic case of Undefined
>> Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you
>> have a bug in your program.
>>     
>
> Sure, I agree it is 99.999999% certain I am doing something wrong
> hence the undefined behaviour. But doesn't it seem somewhat out of the
> ordinary that the behaviour can be affected by which standard library
> header files I include? How can this make a difference to the code
> that gcc produces? It seems unlikely that it's a total coincidence
> that whenever I run the version with iostream included it doesn't
> freeze and whenever I run the version without it does (I just tried
> recompiling the two versions again and the pattern holds).
>
>   
>>> Debugging this is difficult.
>>>       
>> It frequently is ;-) but what other choice do you have? There are tools
>> to help (debuggers such as gdb, memory leak checkers such as
>> valgrind, ...)
>>     
>
> I have used gdb to see which function it freezes in, but as noted I
> cannot compile with full debugging symbols and watch variables/step
> through the code as this removes the bug. valgrind doesn't report any
> problems at all (except a few warnings about functions called in
> external libraries at start up). The reason I originally wanted to
> include iostream was an effort to output the value of variables at
> various points in the function which freezes, but as noted this also
> removes the bug.
>
>   
>> First I would try stripping your program down to a minimal core that
>> exhibits the buggy behaviour. Often in doing so you will isolate and
>> identify the bug. If not seek help here or in a C (or C++, you don't say
>> which language your program is in) forum. You can post minimal code
>> demonstrating the problem.
>>     
>
> But if even including a certain header file can affect the behaviour,
> how can I strip down the program except through random trial and
> error? I guess what I'm trying to say is not "What is wrong with my
> program?", when clearly I haven't given enough information for anyone
> to help, but rather "Does anyone know what sort of thing might be
> affected in the code gcc produces if I include iostream is included?".
>
> (And it is C++ not C, hence <iostream>)
>
> James
>   


-- 
Burlen Loring
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x137

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Wed, Jul 9, 2008 at 5:49 PM, Chris Jefferson <chris@bubblescope.net> wrote:
>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
>> program freezes in a particular function
>>
>> Debugging this is difficult.
>
> While I could well be repeating what others say, my usual tools for
> situations like this, which (touch wood) tend to get me out of it:
>
> A) Turn on all warnings, and read what they say. I've found this kind
> of thing can be caused by a missing return statement.

No warnings...

> B) Turn on the debugging standard library, if you are using any of the
> STL in your code.

OK this reported a problem somewhere else, but fixing it didn't make
any difference to the freezing problem.

> C) Find the minimial set of optimisation flags you need to trigger
> your problem (in particular if you can turn off inlining it will make
> things easier). This makes the next stage easier.

At first it required -finline-functions, but then I manually inlined
an a function called in the part which freezes and now the minimum set
of flags that triggers the problem is:

-O1 -fstrict-aliasing

> D) Use valgrind and see what it comes up with.

Nothing at all.

A minimal version of the function which freezes is something like:

bool AIInterpreter::is_group_like_this(int n_side, int n_group) {
	//it is the second condition (scanned_groups) which triggers this
code branch, but deleting anything at all here removes the bug
	if ((!sides[n_side].groups[n_group].get_alive())
	|| !sides[my_side].scanned_groups[n_side][n_group]
	|| sides[n_side].groups[n_group].get_in_hangar()) {		
		while (l_iter != l_end)
			++l_iter;
		return false;
	}
	write_log(L"it never gets this far");

	<the function continues but though deleting it removes the bug, the
fact the above log never gets written means it is probably irrelevant>
}

So I guess "while (l_iter != l_end)" is becoming an infinite loop, but
if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it
removes the bug and b) there is nothing obviously wrong. Anything else
I can do?

James

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Sat, Jul 12, 2008 at 9:38 PM, James Gregory <james.jrg@gmail.com> wrote:
> I don't understand assembler, but

Actually it is clearly still C++ not assembler, I meant "I don't
understand the resulting lower level code".

James

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Wed, Jul 9, 2008 at 5:49 PM, Chris Jefferson <chris@bubblescope.net> wrote:
> 2008/7/9 James Gregory <james.jrg@gmail.com>:

>> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
>> program freezes in a particular function
>> 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and
>> include <iostream> at the top of the file where the function which
>> freezes is defined: my program doesn't freeze

Chris Jefferson suggested I add the compiler flag "-fdump-tree-all". I
did this for the build which included iostream and the one which
didn't, produced a diff of the final code produced for the problematic
source file between each version, cropped it a bit, and came up with
the following. I don't understand assembler, but the header file
inclusion has clearly changed the code gcc produces. The obvious
differences are:

1. The existence of the line "-Invalid sum of incoming frequencies
873, should be 0" in the freezing version
2. The replacement of this in the version which freezes:

-  const unsigned char * this___l_iterthis__I___M_currentthis____.4618;
-  const unsigned char * this___l_iterthis__I___M_currentthis____.4617;
-  const unsigned char * this___l_iterthis__I___M_currentthis____.4616;

to this in the version which doesn't:

+  unsigned char temp.4650;
+  unsigned char temp.4649;
+  unsigned char temp.4648;

Can anyone tell me what is going on here?

--- AIInterpreter.cpp.102t.final_cleanup	2008-07-12 21:21:37.000000000 +0100
+++ ../nofreeze/AIInterpreter.cpp.102t.final_cleanup	2008-07-12
21:23:33.000000000 +0100

<snip>

 bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this,
n_side, n_group, discount_dead, discount_our)
 {
-  int stat_value.4637;
-  const unsigned char * this___l_iterthis__I___M_currentthis____.4618;
-  const unsigned char * this___l_iterthis__I___M_currentthis____.4617;
-  const unsigned char * this___l_iterthis__I___M_currentthis____.4616;
+  int stat_value.4653;
+  unsigned char temp.4650;
+  unsigned char temp.4649;
+  unsigned char temp.4648;
   int give_group;
   int give_side;
-  struct Group_Base * D.100623;
-  bool D.100627;
+  struct Group_Base * D.100677;
+  bool D.100681;
   size_t __n;
-  struct Group_Base * D.100588;
-  const unsigned char * D.86283;
-  const unsigned char & D.86265;
-  unsigned char D.86266;
-  const unsigned char & D.86197;
-  unsigned char D.86198;
-  const unsigned char & D.86143;
-  unsigned char D.86144;
+  struct Group_Base * D.100642;
+  const unsigned char * D.86304;
+  const unsigned char & D.86286;
+  unsigned char D.86287;
+  const unsigned char * D.86270;
+  const unsigned char & D.86218;
+  unsigned char D.86219;
+  const unsigned char * D.86202;
+  const unsigned char & D.86164;
+  unsigned char D.86165;
+  const unsigned char * D.86148;
   size_t __n;
-  struct Side * D.86086;
+  struct Side * D.86107;
   int second_value;
   const unsigned char operator_type;
   int stat_value;
-  const unsigned char & D.68774;
-  unsigned char D.68755;
-  int D.68741;
+  const unsigned char & D.68792;
+  unsigned char D.68773;
+  int D.68759;

 <bb 2>:
-  D.100588 = operator-> (&((sides.D.66353._M_impl._M_start + (struct
Side *) ((long unsigned int) n_side *
256))->groups.D.33422._M_impl._M_start + (struct Group *) ((long
unsigned int) n_group * 16))->h_group);
-  if (D.100588->alive) goto <L1>; else goto <L0>;
+  D.100642 = operator-> (&((sides.D.66353._M_impl._M_start + (struct
Side *) ((long unsigned int) n_side *
256))->groups.D.33422._M_impl._M_start + (struct Group *) ((long
unsigned int) n_group * 16))->h_group);
+  if (D.100642->alive) goto <L1>; else goto <L0>;

 <L0>:;
   if (discount_dead) goto <L8>; else goto <L1>;
@@ -6385,72 +6402,70 @@
 <L1>:;
   __n = (long unsigned int) n_group;
   __n = (long unsigned int) n_side;
-  D.86086 = sides.D.66353._M_impl._M_start;
-  if ((*(((D.86086 + (struct Side *) ((long unsigned int)
this->my_side * 256))->scanned_groups.D.34444._M_impl._M_start +
(struct vector<bool,std::allocator<bool> > *) (__n *
40))->D.67000._M_impl._M_start.D.26400._M_p + (_Bit_type *) ((__n >>
6) * 8)) & 1 << (int) ((unsigned int) __n & 63)) == 0) goto <L8>; else
goto <L2>;
+  D.86107 = sides.D.66353._M_impl._M_start;
+  if ((*(((D.86107 + (struct Side *) ((long unsigned int)
this->my_side * 256))->scanned_groups.D.34444._M_impl._M_start +
(struct vector<bool,std::allocator<bool> > *) (__n *
40))->D.67000._M_impl._M_start.D.26400._M_p + (_Bit_type *) ((__n >>
6) * 8)) & 1 << (int) ((unsigned int) __n & 63)) == 0) goto <L8>; else
goto <L2>;

 <L2>:;
-  D.100623 = operator-> (&((D.86086 + (struct Side *) (__n *
256))->groups.D.33422._M_impl._M_start + (struct Group *) (__n *
16))->h_group);
-  D.100627 = OBJ_TYPE_REF(*(D.100623->_vptr.Group_Base +
152B);D.100623->19) (D.100623);
-  if (D.100627 != 0) goto <L8>; else goto <L3>;
+  D.100677 = operator-> (&((D.86107 + (struct Side *) (__n *
256))->groups.D.33422._M_impl._M_start + (struct Group *) (__n *
16))->h_group);
+  D.100681 = OBJ_TYPE_REF(*(D.100677->_vptr.Group_Base +
152B);D.100677->19) (D.100677);
+  if (D.100681 != 0) goto <L8>; else goto <L3>;

 <L3>:;
-  if (this->my_side != n_side) goto <L160>; else goto <L4>;
+  if (this->my_side != n_side) goto <L163>; else goto <L4>;

 <L4>:;
-  if (this->my_group != n_group) goto <L160>; else goto <L5>;
+  if (this->my_group != n_group) goto <L163>; else goto <L5>;

 <L5>:;
-  if (discount_our) goto <L8>; else goto <L160>;
+  if (discount_our) goto <L8>; else goto <L163>;

 <L8>:;
-  D.86143 = this->l_iter._M_current;
-  if (D.86143 == this->l_end._M_current) goto <L36>; else goto <L103>;
+  D.86164 = this->l_iter._M_current;
+  if (D.86164 == this->l_end._M_current) goto <L36>; else goto <L103>;

 <L103>:;
-  D.86144 = *D.86143;
-  if (D.86144 == 157) goto <L36>; else goto <L104>;
+  temp.4648 = *D.86164;
+  if (temp.4648 == 157) goto <L36>; else goto <L104>;

 <L104>:;
-  if (D.86144 == 158) goto <L36>; else goto <L120>;
+  if (temp.4648 == 158) goto <L36>; else goto <L166>;

-<L120>:;
-  this___l_iterthis__I___M_currentthis____.4616 = (const unsigned
char *) ((long unsigned int) D.86143 + 1);
+<L39>:;
+  D.86165 = *D.86148;
+  if (D.86165 == 157) goto <L36>; else goto <L40>;

-Invalid sum of incoming frequencies 873, should be 0
 <L40>:;
-  this___l_iterthis__I___M_currentthis____.4616 = (const unsigned
char *) ((long unsigned int)
this___l_iterthis__I___M_currentthis____.4616 + 1);
-  if (D.86144 == 157) goto <L162>; else goto <L40>;
+  if (D.86165 == 158) goto <L36>; else goto <L166>;

-Invalid sum of incoming frequencies 0, should be 301
-<L162>:;
-  this->l_iter._M_current = this___l_iterthis__I___M_currentthis____.4616;
-  D.68741 = 0;
-  goto <bb 42> (<L174>);
+<L166>:;
+  D.86148 = this->l_iter._M_current + 1B;
+  this->l_iter._M_current = D.86148;
+  if (this->l_end._M_current == D.86148) goto <L36>; else goto <L39>;

<snip>

James

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Sat, Jul 12, 2008 at 9:38 PM, James Gregory <james.jrg@gmail.com> wrote:

In a more readable fashion, the difference between the two versions is:

///////////////
Include <iostream>, no freeze:
///////////////

;; Function bool AIInterpreter::is_group_like_this(int, int, bool,
bool) (_ZN13AIInterpreter18is_group_like_thisEiibb)

Removing basic block 39
bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this,
n_side, n_group, discount_dead, discount_our)
{
  unsigned char temp.4650;
  unsigned char temp.4649;
  unsigned char temp.4648;

  const unsigned char * D.86270;
  unsigned char D.86219;
  const unsigned char * D.86202;
  unsigned char D.86165;
  const unsigned char * D.86148;

<L39>:;
  D.86165 = *D.86148;
  if (D.86165 == 157) goto <L36>; else goto <L40>;

<L40>:;
  if (D.86165 == 158) goto <L36>; else goto <L166>;

<L166>:;
  D.86148 = this->l_iter._M_current + 1B;
  this->l_iter._M_current = D.86148;
  if (this->l_end._M_current == D.86148) goto <L36>; else goto <L39>;

///////////////
Don't include <iostream>, freeze:
///////////////

;; Function bool AIInterpreter::is_group_like_this(int, int, bool,
bool) (_ZN13AIInterpreter18is_group_like_thisEiibb)

Removing basic block 39
bool AIInterpreter::is_group_like_this(int, int, bool, bool) (this,
n_side, n_group, discount_dead, discount_our)
{
  const unsigned char * this___l_iterthis__I___M_currentthis____.4618;
  const unsigned char * this___l_iterthis__I___M_currentthis____.4617;
  const unsigned char * this___l_iterthis__I___M_currentthis____.4616;

  unsigned char D.86198;
  unsigned char D.86144;

<L120>:;
  this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char
*) ((long unsigned int) D.86143 + 1);

Invalid sum of incoming frequencies 873, should be 0
<L40>:;
  this___l_iterthis__I___M_currentthis____.4616 = (const unsigned char
*) ((long unsigned int) this___l_iterthis__I___M_currentthis____.4616
+ 1);
  if (D.86144 == 157) goto <L162>; else goto <L40>;

Invalid sum of incoming frequencies 0, should be 301
<L162>:;
  this->l_iter._M_current = this___l_iterthis__I___M_currentthis____.4616;
  D.68741 = 0;
  goto <bb 42> (<L174>);

Re: Including <iostream> affects whether or not program freezes?

[Christoph Bartoschek]

Am Donnerstag 10 Juli 2008 schrieb James Gregory:
> A minimal version of the function which freezes is something like:
>
> bool AIInterpreter::is_group_like_this(int n_side, int n_group) {
> 	//it is the second condition (scanned_groups) which triggers this
> code branch, but deleting anything at all here removes the bug
> 	if ((!sides[n_side].groups[n_group].get_alive())
>
> 	|| !sides[my_side].scanned_groups[n_side][n_group]
> 	|| sides[n_side].groups[n_group].get_in_hangar()) {
>
> 		while (l_iter != l_end)
> 			++l_iter;
> 		return false;
> 	}
> 	write_log(L"it never gets this far");
>
> 	<the function continues but though deleting it removes the bug, the
> fact the above log never gets written means it is probably irrelevant>
> }
>
> So I guess "while (l_iter != l_end)" is becoming an infinite loop, but
> if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it
> removes the bug and b) there is nothing obviously wrong. Anything else
> I can do?

Did you find the bug? What was the problem?

If you did not find it yet:

1. Check with a debugger that the while loop is indeed an endless loop.
2. You did not show what containers l_iter and l_end come from and what 
happens with the containers in this function.

Christoph

Re: Including <iostream> affects whether or not program freezes?

[James Gregory]

On Tue, Aug 5, 2008 at 7:45 AM, Christoph Bartoschek <bartoschek@gmx.de> wrote:

>> So I guess "while (l_iter != l_end)" is becoming an infinite loop, but
>> if I log the value of &(*l_iter) and &(*l_end) on each loop then a) it
>> removes the bug and b) there is nothing obviously wrong. Anything else
>> I can do?
>
> Did you find the bug? What was the problem?
>
> If you did not find it yet:
>
> 1. Check with a debugger that the while loop is indeed an endless loop.
> 2. You did not show what containers l_iter and l_end come from and what
> happens with the containers in this function.
>
> Christoph
>

I never did find the bug, no.

1. I thought gdb couldn't give accurate line numbers for optimized code?

In this slightly modified version of my code (I was attempting to cut
down the code as much as possible):

bool get_true() {
	return true;
}

bool AIInterpreter::is_group_like_this(int n_side, int n_group) {
	if ((!get_true())
	|| !sides[my_side].scanned_groups[n_side][n_group]
	|| !get_true()) {
		while (l_iter != l_end)
			++l_iter;
		return false;
	}
	write_log(L"it never gets this far");

gdb says:

Program received signal SIGINT, Interrupt.
0x0000000000404356 in AIInterpreter::is_group_like_this (this=0x659338,
    n_side=1, n_group=0) at src/AIInterpreter.cpp:388
388		if ((!get_true())
(gdb) bt
#0  0x0000000000404356 in AIInterpreter::is_group_like_this (this=0x659338,
    n_side=1, n_group=0) at src/AIInterpreter.cpp:388

I can't see how it could freeze on that line?

2. l_iter and l_end are of type std::basic_string<unsigned char>::const_iterator
As for what happens to the container, the full source code for the
cut-down version of the file is here:
http://rrgbis.svn.sourceforge.net/viewvc/rrgbis/rrgbis-bug/src/AIInterpreter.cpp?view=markup

And yes the code is a bit of a mess but hey I wrote that file years ago.

The "rrgbis-bug" directory is/was my attempt to find the minimal
amount of code required to make it freeze, though it's still almost
7000 lines of code in total, so I didn't really succeed.

I am no longer subscribed to gcc-help, so if anyone wants me to see a
reply please include me in the cc list.

Thanks,

James