On Monday 24 April 2006 14:01, Per Jessen wrote:
That might easily be a usage problem (who owns what resource, who has to free allocated memory, ...).
Yeah, I think so too - but wouldn't that show on the heap, rather than in the stack?
Not neccessarily. A dangling pointer can overwrite memory anywhere. A pointer to a local object that is returned from a function, then dereferenced and written to will corrupt your stack for sure. A common mistake is to release objects too soon. I don't know any more details about your project, but that one happened to me lately, too: for ( SomeList::iterator it = myList().begin(); it != myList().end(); ++it ) { ... } In this example, myList() would return a temporary list. Being sure that both calls to myList() would refer to the same object, I made that mistake to create two temporary lists, use each to return an interator and compare them. Only the iterators would refer to different objects and thus the comparison would only match by coincidence... and writing to the content of that iterator would wreck the stack for sure. Just to give you an example of how the application can easily mess up its own stack with that kind of thing. ;-)
This has so far always hit the same function, called as part of cl_scanfile(). And always with a very clear stack corruption.
I have no clue about that lib. Maybe there is a missing initialization or
something like that.
CU
--
Stefan Hundhammer