Re: [Bayes++] Crash on destruction of SIR_scheme
Brought to you by:
mistevens
Menu
▾
▴
Re: [Bayes++] Crash on destruction of SIR_scheme
|
From: yon <yo...@ci...> - 2007-09-08 22:57:34
|
Hello Michael, Copying this message to the list in case it may be useful to others. Following up on my previous email, the resamples vector has a valid =20 memory allocation inside the SIR_scheme constructor when it is =20 created, as I am able to verify in the debugger. As soon as I step =20 from that constructor back out to the constructor of the class I =20 derived from SIR_scheme, the _M_finish ptr of resamples' allocator is =20= invalid in the way I described before. Program-wise, nothing occurs =20 between (not even the constructors of other members are called yet), =20 except that the context in which I am looking at this variable changes. As noted earlier, when I destroy my class instance, the program is =20 stuck in an infinite loop due to the invalid _M_finish ptr, as I =20 verify in the debugger. I can't see any way for this to be occuring. I'm going to try to =20 change some project related settings and rearrange the order of =20 members of the class to see if there is any change in behavior. Thanks for any advice, Yon On Sep 7, 2007, at 12:03 PM, yon wrote: > Thank you for the feedback and insight. > > I can report that the state of the SIR_scheme resamples allocator =20 > seems to be invalid after construction. My class's constructor =20 > invokes the SIR_scheme constructor with an s_size argument of 130. =20= > This argument is passed to the resamples constructor as the s_size =20 > parameter. Then when control returns to my class's constructor =20 > after SIR_scheme is constructed, the resamples's allocator's =20 > _M_finish pointer is equal to the s_size argument of 130 (=3D0x82) =20 > instead of _M_start + 130. I don't see any way that I could have =20 > corrupted this pointer in between when SIR_scheme is constructed =20 > and when control returns to the class constructor that called it =20 > (which is inherited from SIR_scheme). > > As I noted, when resamples is then destroyed, it is stuck in an =20 > infinite loop iterating _M_start until an _M_finish value that =20 > precedes it. > > I felt too that the error more likely to be in my own code, however =20= > I am at a loss to explain this behavior, or to understand why I did =20= > not encounter it before. The latter observation would certainly =20 > point to an error somewhere in my code. > > For the reason I mention here, watching that location in memory is =20 > not too useful, because none of my code is called before the =20 > object's state appears to be invalidated. > > Thanks for any advice. > > Regards, > Yon > > > On Sep 6, 2007, at 5:21 AM, Michael Stevens wrote: > >> Hello, >> >> On Thursday 06 September 2007 06:02, yon wrote: >>> Hello, >>> >>> Just to follow up, I have isolated the problem to the resamples >>> member of SIR_scheme. >>> >>> The allocator for the underlying vector of unsigned ints obtains an >>> invalid finish ptr at some point, as noted, which causes the program >>> to hang when deconstructed. >>> >>> I don't think this member is touched in my code in the case under >>> consideration, but am attempting to isolate where this occurs. >>> >>> If someone knows what operations can modify the finish ptr of the >>> vector allocator for such a vector (some sort of invalid resize >>> operation?), that would be helpful to know. >> >> I think the most likely is probably an array overflow or pointer =20 >> problem >> causing the finish ptr to be corrupted. This could be in Bayes++ =20 >> but much >> more likely to be in your code :-) >> >> Not sure what system you are developing with but the debugger can =20 >> help you out >> here. Certainly the Visual C++ debugger has the ability to set a =20 >> breakpoint >> which is trigger when a memory location is modifed. You can use =20 >> this to find >> any corruption of the finish ptr. >> Alternatively under Linux you the valgrind tool is very helpful to =20= >> look for >> incorrect memory access. >> >> Good luck, >> Michael >> --=20 >> ___________________________________ >> Michael Stevens Systems Engineering >> >> 34128 Kassel, Germany >> Phone/Fax: +49 561 5218038 >> >> Navigation Systems, Estimation and >> Bayesian Filtering >> http://bayesclasses.sf.net >> ___________________________________ >> >> ---------------------------------------------------------------------=20= >> ---- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a =20 >> browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Bayesclasses-general mailing list >> Bay...@li... >> https://lists.sourceforge.net/lists/listinfo/bayesclasses-general > > __________________________________ > Yon Visell > > Centre for Intelligent Machines, McGill University > http://cim.mcgill.ca/~yon > > CIRMMT, Schulich School of Music, McGill University > http://www.music.mcgill.ca/cirmmt > > University of Applied Sciences & Arts Z=FCrich > CLOSED: Closing the loop of sound evaluation and design > http://closed.ircam.fr > > Zero-Th Association, Pula, Croatia > http://www.zero-th.org > > Tel +1 514 967 1648 > Fax +1 415 520 0193 > > > __________________________________ Yon Visell Centre for Intelligent Machines, McGill University http://cim.mcgill.ca/~yon CIRMMT, Schulich School of Music, McGill University http://www.music.mcgill.ca/cirmmt University of Applied Sciences & Arts Z=FCrich CLOSED: Closing the loop of sound evaluation and design http://closed.ircam.fr Zero-Th Association, Pula, Croatia http://www.zero-th.org Tel +1 514 967 1648 Fax +1 415 520 0193 |
