Friedrich Foerster wrote: > however, currently IMP.em/EMBED is not working anymore, at least for > me. the essential unit test test_em_fit.py does not work on my > machine. apparently, the parameter initialization does not work. the > test crashes with a segmentation fault.

That's odd - it works just fine here on all of our test machines. You should try a fresh checkout - perhaps something got messed up in your copy of IMP. If that still doesn't work, build with 'scons build=debug' then run the test through gdb to figure out where it's crashing. What kind of machine are you running on?

Ben

frido - can you send the python lines you use to run the procedure ? On Apr 28, 2009, at 7:44 AM, Friedrich Foerster wrote:

> i recompiled the code taking out build="fast". then the unit tests > actually work. however, imp is way too slow to do any serious > calculations with the default-whatever-it-does. > apparently, what is happening is that the parameter setting in > SampledDensityMap::resample fails. when the code tries to use the > unset pointers, the unit test fails with a segmentation fault. > it would be great if an imp expert could look into that. > > thanks > > frido > > > On Apr 28, 2009, at 4:11 PM, Ben Webb wrote: > >> Friedrich Foerster wrote: >>> however, currently IMP.em/EMBED is not working anymore, at least for >>> me. the essential unit test test_em_fit.py does not work on my >>> machine. apparently, the parameter initialization does not work. the >>> test crashes with a segmentation fault. >> >> That's odd - it works just fine here on all of our test machines. You >> should try a fresh checkout - perhaps something got messed up in your >> copy of IMP. If that still doesn't work, build with 'scons >> build=debug' >> then run the test through gdb to figure out where it's crashing. What >> kind of machine are you running on? >> >> Ben >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > -- > > Friedrich Foerster > Max-Planck Institut fuer Biochemie > Am Klopferspitz 18 > D-82152 Martinsried > > Tel: +49 89 8578 2651 > Fax: +49 89 8578 2641 > > foerster@biochem.mpg.de > > www.tomotronic.org > > > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev

I can reproduce this (well, actually I get lots of crashees with tests and fast builds, not just this). I'll try to figure out what is up.

BTW the 'release' flag was replaced by build='release'

On Tue, Apr 28, 2009 at 12:31 PM, Friedrich Foerster < foerster@biochem.mpg.de> wrote:

> calgary 200% ${IMP}/bin/imppy.sh ${MODINSTALLSVN}/bin/modpy.sh python > modules/em/test/test_calc_cc/test_correlation.py > Initializing key table with index 8974343 > Initializing key table with index 90784334 > Segmentation fault > > should be reproducible on your machines if you compile with > build="fast" and release=1 > > cheers > > frido > > On Tue, Apr 28, 2009 at 4:48 PM, Keren Lasker kerenl@salilab.org wrote: > > frido - can you send the python lines you use to run the procedure ? > > On Apr 28, 2009, at 7:44 AM, Friedrich Foerster wrote: > > > >> i recompiled the code taking out build="fast". then the unit tests > >> actually work. however, imp is way too slow to do any serious > calculations > >> with the default-whatever-it-does. > >> apparently, what is happening is that the parameter setting in > >> SampledDensityMap::resample fails. when the code tries to use the unset > >> pointers, the unit test fails with a segmentation fault. > >> it would be great if an imp expert could look into that. > >> > >> thanks > >> > >> frido > >> > >> > >> On Apr 28, 2009, at 4:11 PM, Ben Webb wrote: > >> > >>> Friedrich Foerster wrote: > >>>> > >>>> however, currently IMP.em/EMBED is not working anymore, at least for > >>>> me. the essential unit test test_em_fit.py does not work on my > >>>> machine. apparently, the parameter initialization does not work. the > >>>> test crashes with a segmentation fault. > >>> > >>> That's odd - it works just fine here on all of our test machines. You > >>> should try a fresh checkout - perhaps something got messed up in your > >>> copy of IMP. If that still doesn't work, build with 'scons build=debug' > >>> then run the test through gdb to figure out where it's crashing. What > >>> kind of machine are you running on? > >>> > >>> Ben > >>> -- > >>> ben@salilab.org http://salilab.org/~ben/http://salilab.org/%7Eben/ > >>> "It is a capital mistake to theorize before one has data." > >>> - Sir Arthur Conan Doyle > >>> _______________________________________________ > >>> IMP-dev mailing list > >>> IMP-dev@salilab.org > >>> https://salilab.org/mailman/listinfo/imp-dev > >>> > >> > >> -- > >> > >> Friedrich Foerster > >> Max-Planck Institut fuer Biochemie > >> Am Klopferspitz 18 > >> D-82152 Martinsried > >> > >> Tel: +49 89 8578 2651 > >> Fax: +49 89 8578 2641 > >> > >> foerster@biochem.mpg.de > >> > >> www.tomotronic.org > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> IMP-dev mailing list > >> IMP-dev@salilab.org > >> https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >

thanks, greatly appreciated. however, Rev: 2695 (trunk) did still result in the segmentation fault ... is it located in another branch?

thanks

frido

On Tue, Apr 28, 2009 at 11:56 PM, Daniel Russel drussel@gmail.com wrote: > It should be fixed in svn. There was a problem with how the python wrappers > were built with build=fast. > > On Tue, Apr 28, 2009 at 2:30 PM, Daniel Russel drussel@gmail.com wrote: >> >> I can reproduce this (well, actually I get lots of crashees with tests and >> fast builds, not just this). >> I'll try to figure out what is up. >> >> BTW the 'release' flag was replaced by build='release' >> >> On Tue, Apr 28, 2009 at 12:31 PM, Friedrich Foerster >> foerster@biochem.mpg.de wrote: >>> >>> calgary 200%  ${IMP}/bin/imppy.sh ${MODINSTALLSVN}/bin/modpy.sh python >>> modules/em/test/test_calc_cc/test_correlation.py >>> Initializing key table with index 8974343 >>> Initializing key table with index 90784334 >>> Segmentation fault >>> >>> should be reproducible on your machines if you compile with >>> build="fast" and release=1 >>> >>> cheers >>> >>> frido >>> >>> On Tue, Apr 28, 2009 at 4:48 PM, Keren Lasker kerenl@salilab.org wrote: >>> > frido - can you send the python lines you use to run the procedure ? >>> > On Apr 28, 2009, at 7:44 AM, Friedrich Foerster wrote: >>> > >>> >> i recompiled the code taking out build="fast". then the unit tests >>> >> actually work. however, imp is way too slow to do any serious >>> >> calculations >>> >> with the default-whatever-it-does. >>> >> apparently, what is happening is that the parameter setting in >>> >> SampledDensityMap::resample fails. when the code tries to use the >>> >> unset >>> >> pointers, the unit test fails with a segmentation fault. >>> >> it would be great if an imp expert could look into that. >>> >> >>> >> thanks >>> >> >>> >> frido >>> >> >>> >> >>> >> On Apr 28, 2009, at 4:11 PM, Ben Webb wrote: >>> >> >>> >>> Friedrich Foerster wrote: >>> >>>> >>> >>>> however, currently IMP.em/EMBED is not working anymore, at least for >>> >>>> me. the essential unit test test_em_fit.py does not work on my >>> >>>> machine. apparently, the parameter initialization does not work. the >>> >>>> test crashes with a segmentation fault. >>> >>> >>> >>> That's odd - it works just fine here on all of our test machines. You >>> >>> should try a fresh checkout - perhaps something got messed up in your >>> >>> copy of IMP. If that still doesn't work, build with 'scons >>> >>> build=debug' >>> >>> then run the test through gdb to figure out where it's crashing. What >>> >>> kind of machine are you running on? >>> >>> >>> >>>        Ben >>> >>> -- >>> >>> ben@salilab.org                      http://salilab.org/~ben/ >>> >>> "It is a capital mistake to theorize before one has data." >>> >>>        - Sir Arthur Conan Doyle >>> >>> _______________________________________________ >>> >>> IMP-dev mailing list >>> >>> IMP-dev@salilab.org >>> >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> >> >>> >> -- >>> >> >>> >> Friedrich Foerster >>> >> Max-Planck Institut fuer Biochemie >>> >> Am Klopferspitz 18 >>> >> D-82152 Martinsried >>> >> >>> >> Tel: +49 89 8578 2651 >>> >> Fax: +49 89 8578 2641 >>> >> >>> >> foerster@biochem.mpg.de >>> >> >>> >> www.tomotronic.org >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> IMP-dev mailing list >>> >> IMP-dev@salilab.org >>> >> https://salilab.org/mailman/listinfo/imp-dev >>> > >>> > _______________________________________________ >>> > IMP-dev mailing list >>> > IMP-dev@salilab.org >>> > https://salilab.org/mailman/listinfo/imp-dev >>> > >>> > >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >

The EM crash is fixed now. The problem was a standard rookie error probably compounded by unclear docs :-) As a general rule

- You should never depend on the side effects of asserts and such error checking code for correctness (in any project). In IMP this means that IMP_assert and IMP_check statements are there to help catch you if you do things wrong and have checks turned on. But you cannot count on their behavior. If you want to throw an exception when something happens, as opposed to check for a usage error) throw the exception yourself.

Since there was no reason to throw an exception there, I changed it to returning NULL which is probably faster.

On Tue, Apr 28, 2009 at 3:38 PM, Daniel Russel drussel@gmail.com wrote:

> You are right. The general problems caused by the NDEBUG flag went away, > but the problems with EM remain (it was hard to tell since many of the tests > fail when checks are turned off, which is kind of bad). > > > On Tue, Apr 28, 2009 at 3:25 PM, Friedrich Foerster < > foerster@biochem.mpg.de> wrote: > >> thanks, greatly appreciated. >> however, Rev: 2695 (trunk) did still result in the segmentation fault ... >> is it located in another branch? >> >> thanks >> >> frido >> >> On Tue, Apr 28, 2009 at 11:56 PM, Daniel Russel drussel@gmail.com >> wrote: >> > It should be fixed in svn. There was a problem with how the python >> wrappers >> > were built with build=fast. >> > >> > On Tue, Apr 28, 2009 at 2:30 PM, Daniel Russel drussel@gmail.com >> wrote: >> >> >> >> I can reproduce this (well, actually I get lots of crashees with tests >> and >> >> fast builds, not just this). >> >> I'll try to figure out what is up. >> >> >> >> BTW the 'release' flag was replaced by build='release' >> >> >> >> On Tue, Apr 28, 2009 at 12:31 PM, Friedrich Foerster >> >> foerster@biochem.mpg.de wrote: >> >>> >> >>> calgary 200% ${IMP}/bin/imppy.sh ${MODINSTALLSVN}/bin/modpy.sh python >> >>> modules/em/test/test_calc_cc/test_correlation.py >> >>> Initializing key table with index 8974343 >> >>> Initializing key table with index 90784334 >> >>> Segmentation fault >> >>> >> >>> should be reproducible on your machines if you compile with >> >>> build="fast" and release=1 >> >>> >> >>> cheers >> >>> >> >>> frido >> >>> >> >>> On Tue, Apr 28, 2009 at 4:48 PM, Keren Lasker kerenl@salilab.org >> wrote: >> >>> > frido - can you send the python lines you use to run the procedure ? >> >>> > On Apr 28, 2009, at 7:44 AM, Friedrich Foerster wrote: >> >>> > >> >>> >> i recompiled the code taking out build="fast". then the unit tests >> >>> >> actually work. however, imp is way too slow to do any serious >> >>> >> calculations >> >>> >> with the default-whatever-it-does. >> >>> >> apparently, what is happening is that the parameter setting in >> >>> >> SampledDensityMap::resample fails. when the code tries to use the >> >>> >> unset >> >>> >> pointers, the unit test fails with a segmentation fault. >> >>> >> it would be great if an imp expert could look into that. >> >>> >> >> >>> >> thanks >> >>> >> >> >>> >> frido >> >>> >> >> >>> >> >> >>> >> On Apr 28, 2009, at 4:11 PM, Ben Webb wrote: >> >>> >> >> >>> >>> Friedrich Foerster wrote: >> >>> >>>> >> >>> >>>> however, currently IMP.em/EMBED is not working anymore, at least >> for >> >>> >>>> me. the essential unit test test_em_fit.py does not work on my >> >>> >>>> machine. apparently, the parameter initialization does not work. >> the >> >>> >>>> test crashes with a segmentation fault. >> >>> >>> >> >>> >>> That's odd - it works just fine here on all of our test machines. >> You >> >>> >>> should try a fresh checkout - perhaps something got messed up in >> your >> >>> >>> copy of IMP. If that still doesn't work, build with 'scons >> >>> >>> build=debug' >> >>> >>> then run the test through gdb to figure out where it's crashing. >> What >> >>> >>> kind of machine are you running on? >> >>> >>> >> >>> >>> Ben >> >>> >>> -- >> >>> >>> ben@salilab.org http://salilab.org/~ben/http://salilab.org/%7Eben/ >> >>> >>> "It is a capital mistake to theorize before one has data." >> >>> >>> - Sir Arthur Conan Doyle >> >>> >>> _______________________________________________ >> >>> >>> IMP-dev mailing list >> >>> >>> IMP-dev@salilab.org >> >>> >>> https://salilab.org/mailman/listinfo/imp-dev >> >>> >>> >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> Friedrich Foerster >> >>> >> Max-Planck Institut fuer Biochemie >> >>> >> Am Klopferspitz 18 >> >>> >> D-82152 Martinsried >> >>> >> >> >>> >> Tel: +49 89 8578 2651 >> >>> >> Fax: +49 89 8578 2641 >> >>> >> >> >>> >> foerster@biochem.mpg.de >> >>> >> >> >>> >> www.tomotronic.org >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> _______________________________________________ >> >>> >> IMP-dev mailing list >> >>> >> IMP-dev@salilab.org >> >>> >> https://salilab.org/mailman/listinfo/imp-dev >> >>> > >> >>> > _______________________________________________ >> >>> > IMP-dev mailing list >> >>> > IMP-dev@salilab.org >> >>> > https://salilab.org/mailman/listinfo/imp-dev >> >>> > >> >>> > >> >>> _______________________________________________ >> >>> IMP-dev mailing list >> >>> IMP-dev@salilab.org >> >>> https://salilab.org/mailman/listinfo/imp-dev >> >> >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> > >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > >