[OpendTect_Developers] Assert Problem

Kristofer Tingdahl kristofer.tingdahl at dgbes.com
Tue Nov 6 12:37:59 CET 2012


Dear David,

we use Coin 3.1.3 in our release, so that is known to work well. To me,
this smells library problems, i.e. that SoQt links against one Coin library
and OpendTect another version. Another possible problem could be that Coin
is not initialized. You can easily check this by breaking in
od_SoOD_initStdClasses(). This call should come far before the assert you
have. If it is not call, the most common cause is that the DTECT_APPL
environment is not set to the base of your build. That variable is read in
OD::ModDepMgr::ModDepMgr. If you step through the constructor, the
relbindir_ and devbindir_ should be set to the directory where the shared
libraries are stored.

I hope this points you in the right direction,


- Kristofer


On Tue, Nov 6, 2012 at 12:01 AM, David d'Angelo <
david.d-angelo at iais.fraunhofer.de> wrote:

>  Hi everybody,
>
> any update on this problem?
> If not, could you post which version of coin, simvoleon and soqt are you
> using to successfully build OpendTect under Linux or Mac?
> Any information is greatly appreciated.
>
> Cheers,
> David
>
>
> On 10/31/12 4:07 PM, David d'Angelo wrote:
>
> Hi folks,
>
> I am trying to compile and run OpendTect 4.4.0 under Ubuntu and Mac. I had
> to made some changes to the CMake files (e.g. the include folder of
> simvoleon was never specified and included), and finally it compiled. I can
> send you a patch of the changes if you are interested.
> However, when running od_main I end up with the following assertation:
>
> #0  0xb7fdd424 in __kernel_vsyscall ()
> #1  0xb7afa1df in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/**
> linux/raise.c:64
> #2  0xb7afd825 in __GI_abort () at abort.c:91
> #3  0xb7af3085 in __assert_fail_base (fmt=0xb7c30c38 "%s%s%s:%u:
> %s%sAssertion `%s' failed.\n%n", assertion=0xb59d4844 "!this->isBad()",
>     file=0xb59d4824 "SoType.cpp", line=739, function=0xb59d4ee0 "SbBool
> SoType::isDerivedFrom(SoType) const") at assert.c:94
> #4  0xb7af3137 in __GI___assert_fail (assertion=0xb59d4844
> "!this->isBad()", file=0xb59d4824 "SoType.cpp", line=739,
>     function=0xb59d4ee0 "SbBool SoType::isDerivedFrom(SoType) const") at
> assert.c:103
> #5  0xb565dd51 in SoType::isDerivedFrom (this=0xbfffe4ae, parent=...) at
> SoType.cpp:739
> #6  0xb5639f7e in SoBase::isOfType (this=0x8748fb8, type=...) at
> SoBase.cpp:623
> #7  0xb564f99d in SoNotList::append (this=0xbfffe5b8, rec=0xbfffe548) at
> SoNotification.cpp:92
> #8  0xb564f9de in SoNotList::append (this=0xbfffe5b8, rec=0xbfffe548,
> field=0x8748fe8) at SoNotification.cpp:108
> #9  0xb55b7a58 in SoField::notify (this=0x8748fe8, nlist=0xbfffe5b8) at
> SoField.cpp:1504
> #10 0xb55b2fdb in SoField::startNotify (this=0x8748fe8) at SoField.cpp:1423
> #11 0xb55b70a0 in valueChanged (resetdefault=1, this=0x8748fe8) at
> SoField.cpp:2508
> #12 SoField::valueChanged (this=0x8748fe8, resetdefault=1) at
> SoField.cpp:2503
> #13 0xb55fb4cd in SoSFVec2f::setValue (this=0x8748fe8, valuearg=...) at
> SoSFVec2f.cpp:57
> #14 0xb77967e5 in uiSoViewerBody::mkAxes() () from libuiCoin.so
> #15 0xb7796b28 in uiSoViewerBody::**uiSoViewerBody(ui3DViewer&,
> uiParent*, char const*) () from libuiCoin.so
> #16 0xb7796d73 in ui3DViewer::mkBody(uiParent*, bool, char const*) () from
> libuiCoin.so
> #17 0xb7797181 in ui3DViewer::ui3DViewer(**uiParent*, bool, char const*)
> () from libuiCoin.so
> #18 0xb7f43e4c in uiODSceneMgr::Scene::Scene(**uiMdiArea*) () from
> libuiODMain.so
> #19 0xb7f43ed4 in uiODSceneMgr::mkNewScene() () from libuiODMain.so
> #20 0xb7f4639b in uiODSceneMgr::addScene(bool, ZAxisTransform*, char
> const*) () from libuiODMain.so
> #21 0xb7f46c2e in uiODSceneMgr::**initMenuMgrDepObjs() () from
> libuiODMain.so
> #22 0xb7f2eed6 in uiODMain::initScene() () from libuiODMain.so
> #23 0xb7f3270a in ODMain(int, char**) () from libuiODMain.so
> #24 0x0804896d in main ()
>
> I tried with the coin-3.1.3 as well as the coin version in the mercurial
> repo.
> Did anybody experience the same problem? Any pointers?
> Which version of coin is known to work with OpendTect?
>
> Cheers,
> David
>
> --
> David d'Angelo, M. Sc.
> Adaptive Reflective Teams
> Fraunhofer IAIS
> Schloss Birlinghoven
> 53754 Sankt Augustin
> Germany
> Fon: +49 (0) 2241 14 3444
> Fax: +49 (0) 2241 14 2040
>
>
>
> _____________________________________________________________
> OpendTect Developers mailing list Developers at opendtect.orghttp://www.opendtect.org/mailman/listinfo/developers
>
> You receive this mail because you are listed on developers at opendtect.org To unsubscribe please go to http://lists.opendtect.org/mailman/options/developers . If you encounter any problems, please contact support at opendtect.org .
>
>
>
> --
> David d'Angelo, M. Sc.
> Adaptive Reflective Teams
> Fraunhofer IAIS
> Schloss Birlinghoven
> 53754 Sankt Augustin
> Germany
> Fon: +49 (0) 2241 14 3444
> Fax: +49 (0) 2241 14 2040
>
>
> _____________________________________________________________
> OpendTect Developers mailing list Developers at opendtect.org
> http://www.opendtect.org/mailman/listinfo/developers
>
> You receive this mail because you are listed on developers at opendtect.orgTo unsubscribe please go to
> http://lists.opendtect.org/mailman/options/developers . If you encounter
> any problems, please contact support at opendtect.org .
>



-- 
Kristofer Tingdahl, Ph. D.
CEO
dGB Earth Sciences
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendtect.org/pipermail/developers/attachments/20121106/cbc2773b/attachment.html>


More information about the Developers mailing list