Hi Dave,
Dave Korn wrote:
libraries were compiled by me on the same machine using gcc4.3.4). When
looking at the problem using GDB, it says it is now going to jump to
subroutine A (finishConstruction()), but instead jumps to subroutine B
(edm::ValueMap<double>::operator+=).
This could be just the ordinary sort of thing that goes on when you compile
with optimisation (and hence inlining) turned on. It looks from the earlier
lines like it's just constructed a std::map as part of the PluginFactory or
PluginFactoryBase constructors, so if that edm::ValueMap is a derivation of
std::map it might well be that finishConstruction() is correctly invoking the
+= operator to append an item, and gdb is showing you the source of the
inlined operator function.
Here's a few pieces of additional information:
- I see this behavior with both "standard" level of optimization
(whatever that is) and -O0.
- If instead of using the 400 Mb DLL, I compile the executable including
all of those .o files directly, the program doesn't crash.
- I ran rebaseall on cygwin and all of the dlls in questions. It still
crashes, but now crashes somewhere else.
So I think first thing you need to do is figure out if maybe it's actually
going the right code path, and has gotten something wrong with the value of j.
Check the value of $eip before and after that final step command and find out
exactly where you're running.
I'll try this when I get back to my office.
Thanks!
Charles
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
