Board index » cppbuilder » STL: clear list

STL: clear list


2006-06-29 03:09:18 PM
cppbuilder95
Hi,
i write an application using bcb6 under win2000. I'm using STL list
defined in the protected section of a class:
std::list<ChequeType>lCheques;
Each time before reading new data into the list i empty it using the
clear() method.
Working using one type of hardware it works OK. Using another type of
hardware
the clear method fails and i get 'access violation' error message.
The hardware i'm using does not have anything to do with the data i get
but anyway,
when changing the hardware the it affect the way it works.
What might cause the 'clear' method of list to fail ? How can it be fixed ?
thanks
Ofer
 
 

Re:STL: clear list

Ofer Gaatone < XXXX@XXXXX.COM >writes:
Quote
Hi,

i write an application using bcb6 under win2000. I'm using STL list
defined in the protected section of a class:

std::list<ChequeType>lCheques;

Each time before reading new data into the list i empty it using the
clear() method. Working using one type of hardware it works
OK. Using another type of hardware the clear method fails and i get
'access violation' error message. The hardware i'm using does not
have anything to do with the data i get but anyway, when changing
the hardware the it affect the way it works. What might cause the
'clear' method of list to fail ? How can it be fixed ?
Without seeing code, it's really hard to say. Perhaps your code has
race-conditions in it, and when they hit the behavior is wrong. On
the machine where it "works" it doesn't trigger, but on a faster
machine (or slower, or whatever) the timing is different, things
happen in a different order, and you hit your bug.
Another possibility isn't the hardware, but the libraries installed on
the machine. Are you sure that the libraries it loads on the
"crashing" machine are the ones it should be loading? Mixing libs
between compiler versions, for example, or even between "patches" can
be problematic.
I *really* doubt the problem has anything to do with the std::list
class, but something else that is going on in your program.
--
Chris (TeamB);
 

Re:STL: clear list

Chris Uzdavinis (TeamB) wrote:
Quote
Ofer Gaatone < XXXX@XXXXX.COM >writes:


>Hi,
>
>i write an application using bcb6 under win2000. I'm using STL list
>defined in the protected section of a class:
>
>std::list<ChequeType>lCheques;
>
>Each time before reading new data into the list i empty it using the
>clear() method. Working using one type of hardware it works
>OK. Using another type of hardware the clear method fails and i get
>'access violation' error message. The hardware i'm using does not
>have anything to do with the data i get but anyway, when changing
>the hardware the it affect the way it works. What might cause the
>'clear' method of list to fail ? How can it be fixed ?


Without seeing code, it's really hard to say. Perhaps your code has
race-conditions in it, and when they hit the behavior is wrong. On
the machine where it "works" it doesn't trigger, but on a faster
machine (or slower, or whatever) the timing is different, things
happen in a different order, and you hit your bug.

Another possibility isn't the hardware, but the libraries installed on
the machine. Are you sure that the libraries it loads on the
"crashing" machine are the ones it should be loading? Mixing libs
between compiler versions, for example, or even between "patches" can
be problematic.

I *really* doubt the problem has anything to do with the std::list
class, but something else that is going on in your program.

Ofer,
if AV gives an error with the address 00000, you can interpret that the
referring object is not get instansinated. Probably your program is
buggy and the first machine is not complaining.
Sabetay
 

{smallsort}

Re:STL: clear list

"Sabetay Toros" < XXXX@XXXXX.COM >wrote in message
Quote
if AV gives an error with the address 00000, you can interpret that the
referring object is not get instansinated. Probably your program is
buggy and the first machine is not complaining.
Sabetay
Sounds more like an attempt to access a null
pointer than an uninstantiated one.
 

Re:STL: clear list

"Duane Hebert" < XXXX@XXXXX.COM >writes:
Quote
"Sabetay Toros" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>if AV gives an error with the address 00000, you can interpret that the
>referring object is not get instansinated. Probably your program is
>buggy and the first machine is not complaining.
>Sabetay

Sounds more like an attempt to access a null
pointer than an uninstantiated one.
Null is more specific, but it's still in the same category.
--
Chris (TeamB);
 

Re:STL: clear list

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
"Duane Hebert" < XXXX@XXXXX.COM >writes:

>"Sabetay Toros" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>>if AV gives an error with the address 00000, you can interpret that the
>>referring object is not get instansinated. Probably your program is
>>buggy and the first machine is not complaining.
>>Sabetay
>
>Sounds more like an attempt to access a null
>pointer than an uninstantiated one.

Null is more specific, but it's still in the same category.
Sure. But it's sometimes easier to find the null access
in the de{*word*81}. I would put a breakpoint on where it's
set to null and step through for example.
At any rate, I would be that it has nothing to do
with clearing the list <g>
 

Re:STL: clear list

Hi,
to make things a little more clear:
The application i write runs on a PC connected via RS232 or TCPIP to the
hardware. The input
that causes my application to crash comes from another application that
runs on the same PC.
Since my application is the only one using STL & it runs always on the
same environment i think there
is no issue of mixings libraries.
This is the code the process the input from the other applictions.
pField = inMsg;
while ((pCh = strchr (pField, '|'))!= NULL)
{
*pCh = 0;
switch (FieldNo)
{
case 0: // Answer prefix
strupr (pField);
if (strcmp(pField, "CD") != 0)
{
DdaLogExec(pPOS, "Unexpected prefix in CH answer");
rc = RC_FALSE;
}
else lCheques.clear(); // Empty list of cheques
break;
case 1: // Status
err = atoi (pField);
if (err != NO_ERROR)
// rc = err;
rc = RC_FALSE;
break;
case 2: // Sub group (club)
SubGroup = atoi (pField);
break;
case 3: // @
if (strcmp(pField, "@") != 0)
{
DdaLogExec(pPOS, "@ expected at this point");
rc = RC_FALSE;
}
break;
default: // load cheques
if ((FieldNo % 2) == 0)
Item.ChqNum = atoi(pField); // Get cheque num
else
{
Item.value = atof (pField); // Get cheque value
lCheques.push_back(Item); // Add to list of cheques
}
break;
}
FieldNo++;
pField = pCh+1;
}
It crushes on the "case 0:" at line " else lCheques.clear(); //
Empty list of cheques"
Should i check lCheques.empty == FALSE before ?
Thanks
Ofer
Chris Uzdavinis (TeamB) wrote:
Quote
Ofer Gaatone < XXXX@XXXXX.COM >writes:



>Hi,
>
>i write an application using bcb6 under win2000. I'm using STL list
>defined in the protected section of a class:
>
>std::list<ChequeType>lCheques;
>
>Each time before reading new data into the list i empty it using the
>clear() method. Working using one type of hardware it works
>OK. Using another type of hardware the clear method fails and i get
>'access violation' error message. The hardware i'm using does not
>have anything to do with the data i get but anyway, when changing
>the hardware the it affect the way it works. What might cause the
>'clear' method of list to fail ? How can it be fixed ?
>
>

Without seeing code, it's really hard to say. Perhaps your code has
race-conditions in it, and when they hit the behavior is wrong. On
the machine where it "works" it doesn't trigger, but on a faster
machine (or slower, or whatever) the timing is different, things
happen in a different order, and you hit your bug.

Another possibility isn't the hardware, but the libraries installed on
the machine. Are you sure that the libraries it loads on the
"crashing" machine are the ones it should be loading? Mixing libs
between compiler versions, for example, or even between "patches" can
be problematic.

I *really* doubt the problem has anything to do with the std::list
class, but something else that is going on in your program.



 

Re:STL: clear list

Excuse me for asking but what is AV ?
Sabetay Toros wrote:
Quote
Chris Uzdavinis (TeamB) wrote:

>Ofer Gaatone < XXXX@XXXXX.COM >writes:
>
>
>>Hi,
>>
>>i write an application using bcb6 under win2000. I'm using STL list
>>defined in the protected section of a class:
>>
>>std::list<ChequeType>lCheques;
>>
>>Each time before reading new data into the list i empty it using the
>>clear() method. Working using one type of hardware it works
>>OK. Using another type of hardware the clear method fails and i get
>>'access violation' error message. The hardware i'm using does not
>>have anything to do with the data i get but anyway, when changing
>>the hardware the it affect the way it works. What might cause the
>>'clear' method of list to fail ? How can it be fixed ?
>
>
>
>Without seeing code, it's really hard to say. Perhaps your code has
>race-conditions in it, and when they hit the behavior is wrong. On
>the machine where it "works" it doesn't trigger, but on a faster
>machine (or slower, or whatever) the timing is different, things
>happen in a different order, and you hit your bug.
>
>Another possibility isn't the hardware, but the libraries installed on
>the machine. Are you sure that the libraries it loads on the
>"crashing" machine are the ones it should be loading? Mixing libs
>between compiler versions, for example, or even between "patches" can
>be problematic.
>
>I *really* doubt the problem has anything to do with the std::list
>class, but something else that is going on in your program.
>
Ofer,
if AV gives an error with the address 00000, you can interpret that
the referring object is not get instansinated. Probably your program
is buggy and the first machine is not complaining.
Sabetay
 

Re:STL: clear list

Ofer Gaatone < XXXX@XXXXX.COM >writes:
Quote
Excuse me for asking but what is AV ?
Access violation. The result of dereferencing an invalid pointer in a
program running on Windows if Windows can detect it.
 

Re:STL: clear list

Ofer Gaatone wrote:
Quote
It crushes on the "case 0:" at line " else lCheques.clear(); //
Empty list of cheques"
Should i check lCheques.empty == FALSE before ?
No. Even if lCheques is empty, it shouldn't crash if you clear it.
Your problem is elsewhere.
Michel
--
----------------------------------------
Michel Leunen
mailto: see my homepage.
C++Builder, BCC5.5.1 Web site:
www.leunen.com/
----------------------------------------
 

Re:STL: clear list

Using the de{*word*81} it fails on the call to empty method.
What might fails before that causes such problem ?
Michel Leunen wrote:
Quote
Ofer Gaatone wrote:

>It crushes on the "case 0:" at line " else lCheques.clear(); //
>Empty list of cheques"
>Should i check lCheques.empty == FALSE before ?


No. Even if lCheques is empty, it shouldn't crash if you clear it.
Your problem is elsewhere.

Michel
 

Re:STL: clear list

Ofer Gaatone wrote:
Quote
Using the de{*word*81} it fails on the call to empty method.
What might fails before that causes such problem ?
First thought is ChequeType::~ChequeType()
might not be correct.
Or some of the other required class support functions might not be
correct. Check your documentation on the class requirements for
std::list.
You haven't mentioned if you are using the RW or STLPort version of
the STL. There might be slight differences.
Is something overflowing and overwriting lCheques?
Is pField guaranteed to be null terminated on entry?
It has potential to overflow if not terminated properly.
One would guess that at the end of the while(), you are using the
accumulated list of checks. That code might mess up the data.
 

Re:STL: clear list

Bob Gonder wrote:
Quote
Ofer Gaatone wrote:



>Using the de{*word*81} it fails on the call to empty method.
>What might fails before that causes such problem ?
>
>

First thought is ChequeType::~ChequeType()
might not be correct.

ChequeType is a structure holding data only & does not have ctor or dtor.
Quote

Or some of the other required class support functions might not be
correct. Check your documentation on the class requirements for
std::list.
You haven't mentioned if you are using the RW or STLPort version of
the STL. There might be slight differences.

Excuse me but what is RW or STLPort ?
Quote


Is something overflowing and overwriting lCheques?

Overwriting no, overflowing i don't think so.
Quote

Is pField guaranteed to be null terminated on entry?

Yes, whenever it finds the delimiter '|' it replaced by null.
Quote
It has potential to overflow if not terminated properly.

One would guess that at the end of the while(), you are using the
accumulated list of checks. That code might mess up the data.





 

Re:STL: clear list

Ofer Gaatone < XXXX@XXXXX.COM >writes:
Quote
>You haven't mentioned if you are using the RW or STLPort version of
>the STL. There might be slight differences.
>
Excuse me but what is RW or STLPort ?
RogueWave or STLPort, they are different implementations of the STL.
Borland used to use RW, switched to STLPort, and most recently
switched again to Dinkumware.
I'd suggest you look for general memory corruption earlier in your
program. Perhaps a problem happens earlier in your program but
doesn't show up until here.
As for mixed libraries, I didn't mean between the client and server,
but between the executable and the dll that it is using. Or perhaps
on one machine you build with one dll, but when you deploy the
application to another machine there is a dll with the SAME NAME on
that machine but it's incompatible with the version against which the
executable was built.
--
Chris (TeamB);
 

Re:STL: clear list

Quote
RogueWave or STLPort, they are different implementations of the STL.
Borland used to use RW, switched to STLPort, and most recently
switched again to Dinkumware.

I'm using STLPort.
Quote

I'd suggest you look for general memory corruption earlier in your
program. Perhaps a problem happens earlier in your program but
doesn't show up until here.

I thought about memory corruption but how come it happens when using one
type of
hardware and not the other ? I might correct the problematic hardware
and cause
a problem to the working one.
Quote

As for mixed libraries, I didn't mean between the client and server,
but between the executable and the dll that it is using. Or perhaps
on one machine you build with one dll, but when you deploy the
application to another machine there is a dll with the SAME NAME on
that machine but it's incompatible with the version against which the
executable was built.


The program is running always on the same machine (mine). So it is using
always the same libraries.