Nasty Bug: First exception error.

[tarmat]

I have a class that has a std::list of ints as a member. Let's say its
this:

std::list<int> MyInts;

Frequently, another list of ints is assigned to MyInts

MyInts = MyOtherInts;

This occasionally gives me a "First-chance exception" error. I haven't
a clue what this is or why it is happening. The problem is in the
following lines of STL code:

_Myt& operator=(const _Myt& _X)
{if (this != &_X)
{iterator _F1 = begin();
iterator _L1 = end();
const_iterator _F2 = _X.begin();
const_iterator _L2 = _X.end();
for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
//here---> *_F1 = *_F2;
erase(_F1, _L1);
insert(_L1, _F2, _L2); }

This is the worst bug I've ever had and i just don't know where to
start with fixing it. I would appreciate any advice you guys have to
offer.

[Alf P. Steinbach]

Re: Nasty Bug: First exception error.

On Tue, 16 Dec 2003 19:09:26 +0530, tarmat <tarmat@btopenw orld.com> wrote:
[color=blue]
>I have a class that has a std::list of ints as a member. Let's say its
>this:
>
>std::list<in t> MyInts;
>
>Frequently, another list of ints is assigned to MyInts
>
>MyInts = MyOtherInts;
>
>This occasionally gives me a "First-chance exception" error. I haven't
>a clue what this is or why it is happening. The problem is in the
>following lines of STL code:
>
> _Myt& operator=(const _Myt& _X)
> {if (this != &_X)
> {iterator _F1 = begin();
> iterator _L1 = end();
> const_iterator _F2 = _X.begin();
> const_iterator _L2 = _X.end();
> for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
> //here---> *_F1 = *_F2;
> erase(_F1, _L1);
> insert(_L1, _F2, _L2); }
>
>This is the worst bug I've ever had and i just don't know where to
>start with fixing it. I would appreciate any advice you guys have to
>offer.[/color]

Generally a "first-chance" exception is benign; you'll get that wherever
an exception is thrown.

However you shouldn't get any exception from the assignment shown.

Best advice: post a _small_, complete program that exhibits the problem.

[Marko Becirevic]

Re: Nasty Bug: First exception error.

> _Myt& operator=(const _Myt& _X)[color=blue]
> {if (this != &_X)
> {iterator _F1 = begin();
> iterator _L1 = end();
> const_iterator _F2 = _X.begin();
> const_iterator _L2 = _X.end();
> for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
> //here---> *_F1 = *_F2;
> erase(_F1, _L1);
> insert(_L1, _F2, _L2); }
>[/color]

Maybe not && but ||. It seems that F2 reaches end, but F1 does not.

for (; _F1 != _L1 || _F2 != _L2; ++_F1, ++_F2)

I'm not sure about this.

[Jerry Coffin]

Re: Nasty Bug: First exception error.

In article <t12utvssncgc3d bujeajavk3f85rs 6mtds@4ax.com>,
tarmat@btopenwo rld.com says...[color=blue]
> I have a class that has a std::list of ints as a member. Let's say its
> this:
>
> std::list<int> MyInts;
>
> Frequently, another list of ints is assigned to MyInts
>
> MyInts = MyOtherInts;
>
> This occasionally gives me a "First-chance exception" error.[/color]

A first-chance exception is NOT an error. If you don't see a second-
chance exception, it means that the exception has been handled, and it's
not an error at all.

It looks like in this case the system has paged out some of the memory
in your list. When you try to read from or write to the memory that's
not present in physical memory, the CPU raises an exception. The OS
then handles that by reading the correct data into memory.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Pete Becker]

Re: Nasty Bug: First exception error.

Marko Becirevic wrote:[color=blue]
>[color=green]
> > _Myt& operator=(const _Myt& _X)
> > {if (this != &_X)
> > {iterator _F1 = begin();
> > iterator _L1 = end();
> > const_iterator _F2 = _X.begin();
> > const_iterator _L2 = _X.end();
> > for (; _F1 != _L1 && _F2 != _L2; ++_F1, ++_F2)
> > //here---> *_F1 = *_F2;
> > erase(_F1, _L1);
> > insert(_L1, _F2, _L2); }
> >[/color]
>
> Maybe not && but ||. It seems that F2 reaches end, but F1 does not.
>
> for (; _F1 != _L1 || _F2 != _L2; ++_F1, ++_F2)
>
> I'm not sure about this.[/color]

&& is correct. The symptoms of memory-related errors often occur far
from the code that actually caused the problem. They're only rarely
caused by code in the standard library.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)