Archived

This forum has been archived. Please start a new discussion on GitHub.

Compilation of cpp fails on OpenSuse 12.2 with gcc 4.7.1

I tried to compile Ice on a OpenSuse 12.2 system from source because I would like to have Python 2.7 support. At first is fails on FileUtil and FileTracker, which could be solved by adding
"#include <unistd.h> "
to the sourrce as suggested in Issue 420 - modpagespeed - Error Compiling on Arch Linux - Apache module for rewriting web pages to reduce latency and bandwidth - Google Project Hosting for a similar problem.

But now I get a segmentation fault:

make[3]: Entering directory `/root/Ice-3.4.2/cpp/src/Ice'
rm -f ../../include/Ice/BuiltinSequences.h BuiltinSequences.cpp
../../bin/slice2cpp --ice --include-dir Ice --dll-export ICE_API -I../../../slice --stream ../../../slice/Ice/BuiltinSequences.ice
make[3]: *** [BuiltinSequences.cpp] Segmentation fault
make[3]: *** Deleting file `BuiltinSequences.cpp'
make[3]: Leaving directory `/root/Ice-3.4.2/cpp/src/Ice'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/root/Ice-3.4.2/cpp/src'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/root/Ice-3.4.2/cpp'
make: *** [all] Error 1

...attached the make output as file. Attachment not found.

Any ideas?

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Can you get the stack trace of the crash with gdb? The following commands should do the job:
    $ export LD_LIBRARY_PATH=/root/Ice-3.4.2/cpp/lib:$LD_LIBRARY_PATH
    $ cd /root/Ice-3.4.2/cpp/src/Ice
    $ gdb ../../bin/slice2cpp
    (gdb) run --ice --include-dir Ice --dll-export ICE_API -I../../../slice --stream ../../../slice/Ice/BuiltinSequences.ice
    <wait for the segfault>
    (gdb) where
    

    Cheers,
    Benoit.
  • benoit wrote: »
    Can you get the stack trace of the crash with gdb?

    Hi Benoit,
    thanks for the reply, thats what I get:

    Starting program: /root/Ice-3.4.2/cpp/bin/slice2cpp --ice --include-dir Ice --dll-export ICE_API -I../../../slice --stream ../../../slice/Ice/BuiltinSequences.ice
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/libthread_db.so.1".
    [New Thread 0xb7a20b40 (LWP 19353)]

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0xb7a20b40 (LWP 19353)]
    0x00000000 in ?? ()
    (gdb)
  • bernard
    bernard Jupiter, FL
    Hi Marco,

    When you get the (gdb) prompt, please type where to get the stack trace, and post it here.

    Thanks,
    Bernard
  • bernard wrote: »
    type where to get the stack trace

    Sorry Bernard:
    (gdb) where
    #0  0x00000000 in ?? ()
    #1  0xb7d74dcb in sigwaitThread () at CtrlCHandler.cpp:183
    #2  0xb7d10e32 in start_thread () from /lib/libpthread.so.0
    #3  0xb7b0e8ee in clone () from /lib/libc.so.6
    
  • bernard
    bernard Jupiter, FL
    Hi Marco,

    I've just tried building on OpenSUSE 12.2 and get the same crash. It's due to a strange problem with our CtrlCHandler that we need to investigate.

    The simplest is to comment out this CtrCHandler in src/slice2cpp/Main.cpp (and src/slice2py/Main.cpp):
        // Does not work on OpenSUSE 12.2
        // IceUtil::CtrlCHandler ctrlCHandler;
        // ctrlCHandler.setCallback(interruptedCallback);
    

    (this CtrCHandler is not important here: it just terminates slice2xxx nicely if you press CTRL-C when compiling)

    Then, unfortunately, Ice 3.4.2 does not compile with GCC 4.7 without some patches. You could use for example http://www.zeroc.com/forums/patches/5647-patch-compiling-ice-clang-gcc4-7-a.html (note: it's not an official or supported patch).

    When you build Ice for C++ - for building the Ice for Python extension - you can stop the build after IceSSL.

    Let me know how it goes.

    Bernard
  • Hi Bernard,
    I did my very best, but no success yet ;-)

    What I've done:
    1. commented out the CtrlCHandler
    2. applied patches from http://www.zeroc.com/forums/patches/5647-patch-compiling-ice-clang-gcc4-7-a.html comment 8 (patch -p0 < {patchfile}) and comment 12 (direct edit)
    3. make clean && make

    Got:

    make[3]: Entering directory `/root/Ice3.4.2/cpp/src/Freeze'
    rm -f ../../include/Freeze/BackgroundSaveEvictor.h BackgroundSaveEvictor.cpp
    ../../bin/slice2cpp --ice --include-dir Freeze --dll-export FREEZE_API -I../../../slice ../../../slice/Freeze/BackgroundSaveEvictor.ice
    mv BackgroundSaveEvictor.h ../../include/Freeze
    rm -f ../../include/Freeze/CatalogData.h CatalogData.cpp
    ../../bin/slice2cpp --ice --include-dir Freeze --dll-export FREEZE_API -I../../../slice ../../../slice/Freeze/CatalogData.ice
    mv CatalogData.h ../../include/Freeze
    rm -f ../../include/Freeze/Catalog.h Catalog.cpp
    ../../bin/slice2freeze --ice --include-dir Freeze --dll-export FREEZE_API -I../../../slice --dict Freeze::Catalog,string,Freeze::CatalogData \
    Catalog ../../../slice/Freeze/CatalogData.ice
    make[3]: *** [Catalog.cpp] Segmentation fault
    make[3]: *** Deleting file `Catalog.cpp'

    What did I wrong?

    Thanks,
    Marco
  • bernard
    bernard Jupiter, FL
    Hi Marco,

    It's the same CtrCHandler problem, this time in slice2freeze.

    If you just want to build Ice for Python (and not Freeze, IceGrid, IceStorm etc.), you can also stop your Ice for C++ build there ... you've already built all you need for Python.

    I also looked into the CtrCHandler crash. CtrCHandler is very simple: it starts a thread that catches CTRL-C -like signals with sigwait. The destructor of the CtrCHandler cancels this thread (with pthread_cancel), typically while it's waiting for a signal in sigwait. Strangely on OpenSUSE 12.2, the pthread_cancel triggers a segmentation fault in the sigwait-ing thread most of the time (but not all the time) ... sounds like a OS or compiler bug.

    Cheers,
    Bernard
  • Hi Bernard,
    the compilation of the Python module worked. I did everything as described in py/INSTALL.

    Now I get:

    omero@S1020-Omero2:~> python
    Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import Ice
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/opt/Ice-3.4.2/python/Ice.py", line 47, in <module>
    import IcePy
    ImportError: /opt/Ice-3.4.2/python/IcePy.so: undefined symbol: _ZN3Ice6upCastEPNS_17UDPConnectionInfoE
    >>>

    Can you please again help me with this error?

    Best,
    Marco
  • bernard
    bernard Jupiter, FL
    Hi Marco,

    Unfortunately this sounds like a problem with the GCC 4.7 patch, or perhaps with the Ice for Python code in Ice 3.4.2.

    With our mainline, once the CtrCHandler is removed, everything seems fine:
    ~/builds/ice/py $ ./allTests.py
    
    *** running tests 1/27 in /root/builds/ice/py/test/Slice/keyword
    *** configuration: Default
    *** test started: 11/14/12 18:58:52
    starting client... ok
    Testing operation name... ok
    Testing generated type names... ok
    
    *** running tests 2/27 in /root/builds/ice/py/test/Slice/structure
    *** configuration: Default
    *** test started: 11/14/12 18:58:52
    starting client... ok
    testing equals() for Slice structures... ok
    
    *** running tests 3/27 in /root/builds/ice/py/test/Ice/adapterDeactivation
    *** configuration: Default
    *** test started: 11/14/12 18:58:53
    starting Server.py... ok
    starting Client.py... ok
    testing stringToProxy... ok
    testing checked cast... ok
    creating/destroying/recreating object adapter... ok
    creating/activating/deactivating object adapter in one operation... ok
    deactivating object adapter in the server... ok
    testing whether server is gone... ok
    starting collocated... ok
    testing stringToProxy... ok
    testing checked cast... ok
    creating/destroying/recreating object adapter... ok
    creating/activating/deactivating object adapter in one operation... ok
    deactivating object adapter in the server... ok
    testing whether server is gone... ok
    
    *** running tests 4/27 in /root/builds/ice/py/test/Ice/binding
    *** configuration: Default
    *** test started: 11/14/12 18:58:55
    starting Server.py... ok
    starting Client.py... ok
    testing binding with single endpoint... ok
    testing binding with multiple endpoints... ok
    testing binding with multiple endpoints and AMI... ok
    testing random endpoint selection... ok
    testing ordered endpoint selection... ok
    testing per request binding with single endpoint... ok
    testing per request binding with multiple endpoints... ok
    testing per request binding with multiple endpoints and AMI... ok
    testing per request binding and ordered endpoint selection... ok
    testing per request binding and ordered endpoint selection and AMI... ok
    testing endpoint mode filtering... ok
    (...)
    

    The simplest would be to wait until the next Ice release, in the very near future.

    Cheers,
    Bernard
  • Hi Bernard,
    thanks for the reply. On my client the Ice3.4.2/py/allTest.py runs fine, too. So I assume there is something wrong with the test? Should'nt it come up with the same error as if I simple do "import Ice" in python itself?

    Of course I can (and will :)) wait on the next release.

    Best,
    Marco
  • benoit
    benoit Rennes, France
    Hi,

    It sounds like an environment problem if the tests work. Most likely the IcePy module is loading the wrong Ice shared library. Do you have different Ice versions installed in several places (like /usr/lib for example)?

    You can run the tests with --env to see the environment variables used to run the tests (e.g.: test/Ice/operations/run.py --env). Most likely, if you use the same PYTHONPATH and LD_LIBRARY_PATH settings it will work.

    Cheers,
    Benoit.
  • [solved]

    Hi Benoit,
    that was what went bad. Now everything is fine!