Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Can Iterators Trash The Heap?

Reply
Thread Tools

Can Iterators Trash The Heap?

 
 
cppaddict
Guest
Posts: n/a
 
      08-27-2004
I'm running a Java application that uses a native C++ library I've
written. The Java application hits one of the native methods pretty
frequently (about 100 ms or so), and while it usually works fine,
sometimes the program crashes with an error message about the heap.

The method which seems to be causing the problem is very simple, and
does no manual manipulation of the heap. But it does use an iterator.
Could this be the issue?

Other things to note about the error. The "Function=" part references
a function that is NEVER used in my app. The method referenced by the
current Java thread referenced is used, however.

I've renamed the methods below for clarity. Everything else is cut
and pasted from the error output.

Thanks for any help,
cpp

------------------ERROR MESSAGE FOLLOWS---------------------------

The Java method

Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
at PC=0x2C9
0A47
Function=Java_MyClass_methodWhichIsNeverUsedInMyAp p+0xA757
Library=C:\myLibrary.dll

Current Java thread:
at MyClass.methodWhichUsesIterator(Native Method)
.......

Heap at VM Abort:
Heap
def new generation total 576K, used 350K [0x10010000, 0x100b0000,
0x104f0000)

eden space 512K, 56% used [0x10010000, 0x10057be0, 0x10090000)
from space 64K, 100% used [0x100a0000, 0x100b0000, 0x100b0000)
to space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
tenured generation total 1408K, used 36K [0x104f0000, 0x10650000,
0x14010000)

the space 1408K, 2% used [0x104f0000, 0x104f91b0, 0x104f9200,
0x10650000)
compacting perm gen total 4096K, used 1186K [0x14010000, 0x14410000,
0x1801000
0)
the space 4096K, 28% used [0x14010000, 0x14138bf0, 0x14138c00,
0x14410000)

 
Reply With Quote
 
 
 
 
tom_usenet
Guest
Posts: n/a
 
      08-27-2004
On Fri, 27 Aug 2004 07:21:10 GMT, cppaddict <(E-Mail Removed)> wrote:

>I'm running a Java application that uses a native C++ library I've
>written. The Java application hits one of the native methods pretty
>frequently (about 100 ms or so), and while it usually works fine,
>sometimes the program crashes with an error message about the heap.
>
>The method which seems to be causing the problem is very simple, and
>does no manual manipulation of the heap. But it does use an iterator.
>Could this be the issue?


If you are using the iterator incorrectly, then yes, of course.
Obviously doing anything at all except assigning to an invalidated
iterator causes undefined behaviour.

Tom
 
Reply With Quote
 
 
 
 
cppaddict
Guest
Posts: n/a
 
      08-27-2004

>If you are using the iterator incorrectly, then yes, of course.
>Obviously doing anything at all except assigning to an invalidated
>iterator causes undefined behaviour.


Sorry, I should have posted the code. Here it is... it test if the
given set of Point - Color values match those at a given position on
the screen:

bool NativeOcr::testPoints(Point positionCoords, std::map<Point,
COLORREF> testPnts) const {

//if one point mismatches, we set it to false and return
bool retVal = true;

std::map<Point, COLORREF>::iterator iter;
int x,y;
for (iter = testPnts.begin(); iter != testPnts.end(); ++iter)
{
Point offset = iter->first;
COLORREF testColor = iter->second;
x = positionCoords.getX() + offset.getX();
y = positionCoords.getY() + offset.getY();
if (GetPixel(hDc_,x,y) != testColor) {
retVal = false;
break;
}
}

return retVal;
}

 
Reply With Quote
 
tom_usenet
Guest
Posts: n/a
 
      08-27-2004
On Fri, 27 Aug 2004 09:47:03 GMT, cppaddict <(E-Mail Removed)> wrote:

>
>>If you are using the iterator incorrectly, then yes, of course.
>>Obviously doing anything at all except assigning to an invalidated
>>iterator causes undefined behaviour.

>
>Sorry, I should have posted the code. Here it is... it test if the
>given set of Point - Color values match those at a given position on
>the screen:
>
>bool NativeOcr::testPoints(Point positionCoords, std::map<Point,
>COLORREF> testPnts) const {


Did you mean to pass the map by value? Something like this would be
better:

bool NativeOcr::testPoints(Point positionCoords, std::map<Point,
COLORREF> const& testPnts) const {
//if one point mismatches, we set it to false and return
bool retVal = true;

std::map<Point, COLORREF>::const_iterator iter,
end = testPnts.end();
int x,y;
for (iter = testPnts.begin(); iter != end; ++iter)
{
Point const& offset = iter->first;
COLORREF testColor = iter->second;
x = positionCoords.getX() + offset.getX();
y = positionCoords.getY() + offset.getY();
if (GetPixel(hDc_,x,y) != testColor) {
retVal = false;
break;
}
}

return retVal;
}

In any case, I couldn't see a bug in the original code, apart from the
noted performance bug. This implies that you must be corrupting the
heap or causing undefined behaviour in another function somewhere.

Tom
 
Reply With Quote
 
cppaddict
Guest
Posts: n/a
 
      08-27-2004

>In any case, I couldn't see a bug in the original code, apart from the
>noted performance bug. This implies that you must be corrupting the
>heap or causing undefined behaviour in another function somewhere.


Any idea why the error I posted is saying that there is an access
violation on a function that is NEVER used ANYWHERE in my app. Can
this be caused by heap overflow?

Here's the relevant part of the error message again:

Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
at PC=0x2C9
0A47
Function=Java_MyClass_methodWhichIsNeverUsedInMyAp p+0xA757

Thanks again,
cpp
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      08-28-2004
cppaddict <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..

[ ... ]

> bool NativeOcr::testPoints(Point positionCoords, std::map<Point,
> COLORREF> testPnts) const {
>
> //if one point mismatches, we set it to false and return
> bool retVal = true;
>
> std::map<Point, COLORREF>::iterator iter;
> int x,y;
> for (iter = testPnts.begin(); iter != testPnts.end(); ++iter)
> {
> Point offset = iter->first;
> COLORREF testColor = iter->second;
> x = positionCoords.getX() + offset.getX();
> y = positionCoords.getY() + offset.getY();
> if (GetPixel(hDc_,x,y) != testColor) {
> retVal = false;
> break;
> }
> }
>
> return retVal;
> }


I don't see an obvious bug in this code -- I suspect you're looking in
the wrong place. OTOH, I'd personally write the code a bit
differently, something along these lines:

// warning: untested code.
typedef std:air<Point, COLORREF> mapped;

struct pt_mm : public std::binary_function<Point, mapped, bool> {
bool operator()(Point const &pos, mapped const &i) const {
HDC hDc_;
Point offset = i.first;

int x = pos.getX() + offset.getX();
int y = pos.getY() + offset.getY();
return GetPixel(hDc_, x, y) != i.second;
}
};

typedef std::map<Point, COLORREF> ptmap;

bool NativeOcr::testPoints(Point const &pos, ptmap const &pts) {
return std::find_if(pts.begin(), pts.end(),
std::bind1st(pt_mm(), pos)) == pts.end();
}

As a less topical aside, if your call to GetPixel is to the one in
Windows, you might want to check in a Windows programming newsgroup
about how to use a DIBSection instead -- it'll probably be quite a bit
faster.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
cppaddict
Guest
Posts: n/a
 
      08-29-2004

>As a less topical aside, if your call to GetPixel is to the one in
>Windows, you might want to check in a Windows programming newsgroup
>about how to use a DIBSection instead -- it'll probably be quite a bit
>faster.


Jerry,

You have a sharp eye. After many hours bug tracking yesterday, I
traced almost all problems in my app (both bugs and speed) to
excessive use of GetPixel. It is:

1. Not thread safe. Having multiple threads access it causes strange
heap and memory exception errors.

2. Slow. I am looking for an alternative now. I'll take a look at
DIBSECTION. I was also thinking of of BitBlt

Let me know if you have any other advice.

Thanks again,
cpp
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      08-29-2004
cppaddict <(E-Mail Removed)> wrote:
> I traced almost all problems in my app (both bugs and speed) to
> excessive use of GetPixel. It is:
>
> 1. Not thread safe. Having multiple threads access it causes strange
> heap and memory exception errors.


You should assume things are not thread-safe, unless there is
specific documentation to the contrary. In particular, any Windows
objects (eg. windows, GDI objects, strings, timers, ...) are most
unlikely to be thread-safe, you should either use mutexes, or only
access them from one thread.

> 2. Slow. I am looking for an alternative now. I'll take a look at
> DIBSECTION. I was also thinking of of BitBlt


GetPixel was designed for occasional use.. if you need to scan a
large area you should retrieve that area to memory first and then
work within that memory. IMHO the windows GDI interface is horrible,
I'd suggest you use some other graphics library for manipulating
images and then blit them to the screen when appropriate.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
plain iterators and reverse iterators on vector subramanian100in@yahoo.com, India C++ 10 08-08-2009 08:28 AM
Re: Trash Can and Sun Andrew Thompson Java 7 05-28-2008 01:16 AM
Re: Trash Can and Sun Roedy Green Java 1 05-28-2008 12:39 AM
Iterators and reverse iterators Marcin Kaliciński C++ 1 05-08-2005 09:58 AM
Epson Stylus Photo 780: Trash It Or Can It Be Saved? Uncle_Alias Digital Photography 5 07-04-2003 07:00 PM



Advertisments