#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7

    Unhappy Segmentation Fault (core dumped) while connecting thru DBD::Oracle


    Hello Everyone,

    Starting a new thread as the other thread was getting confusing with no clear objective. Here are the details and issue towards end:

    Downloaded ExtUtils-MakeMaker-6.56, DBI-1.54 and DBD-Oracle-1.24

    My Perl Version - v5.8.8 built for sun4-solaris-thread-multi-64int

    <Setting up environment>
    # export PERL5LIB=/opt/myperl/lib/

    <oracle_home is set to 11gR2 11.2.0.2.0 64-bit client>
    # export ORACLE_HOME=/oracle11g/app/ora11g/product/11.2.0/client_1/

    <LD_LIBRARY_PATH is set to 11gR2 11.2.0.2.0 32-bit client this is because am using 32-bit perl and hence for compilation of Oracle.so this will be required>
    export LD_LIBRARY_PATH=/ora11gR2/app/ora11gR2/product/11.2.0/client_1/lib/

    <Installing ExtUtils-MakeMaker>
    # cd ExtUtils-MakeMaker-6.56
    # perl Makefile.PL
    # make
    # make install
    -----succeeded-----
    <Installing DBI-1.54>
    # cd DBI-1.54
    # perl Makefile.PL
    # make
    gcc -c -D_REENTRANT -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\"1.54\" -DXS_VERSION=\"1.54\" -fPIC "-I/opt/myperl/lib/5.8.8/sun4-solaris-thread-multi-64int/CORE" -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter Perl.c
    sh: gcc: not found
    *** Error code 1
    make: Fatal error: Command failed for target `Perl.o'


    <Installed gcc in /usr/local/bin
    # gcc -v
    Thread model: posix
    gcc version 3.4.6
    >


    # export PATH=/usr/local/bin/:$PATH
    # make
    # make install
    -----succeeded-----

    <Installing DBD-Oracle-1.24>
    # cd DBD-Oracle-1.24
    # perl Makefile.PL
    Oracle version 11.2.0.1 (11.2) Unable to locate an oracle.mk, proc.mk or other suitable *.mk file in your Oracle installation. (I looked in /oracle11g/app/ora11g/product/11.2.0/client_1/rdbms/demo/demo_rdbms32.mk /oracle11g/app/ora11g/product/11.2.0/client_1/precomp/demo/proc/proc.mk /oracle11g/app/ora11g/product/11.2.0/client_1/precomp/demo/proc/demo_proc.mk /oracle11g/app/ora11g/product/11.2.0/client_1/proc/lib/proc.mk /oracle11g/app/ora11g/product/11.2.0/client_1/proc16/lib/proc16.mk /usr/share/oracle/11.2/client/demo.mk /usr/share/oracle/11.2/client64/demo.mk under /oracle11g/app/ora11g/product/11.2.0/client_1) The oracle.mk (or demo_rdbms.mk) file is part of the Oracle RDBMS product. The proc.mk (or demo_proc.mk) file is part of the Oracle Pro*C product. You need to build DBD::Oracle on a system which has one of these Oracle components installed. (Other *.mk files such as the env_*.mk files will not work.) Alternatively you can use Oracle Instant Client. In the unlikely event that a suitable *.mk file is installed somewhere non-standard you can specify where it is using the -m option: perl Makefile.PL -m /path/to/your.mk See the appropriate README file for your OS for more information and some alternatives. at Makefile.PL line 1095.

    Followed ReadMe and then used flag -l
    # perl Makefile.PL -l
    # make
    # make install
    -----succeeded-----

    Now with all these compiled and installed modules I try to connect to database with a simple perl file and it throws 'Segmentation Fault' error.

    # perl test.pl
    Segmentation Fault (core dumped)
    # pstack core
    core 'core' of 20119: perl test.pl
    fef4fdd4 XS_DBD__Oracle__dr_init_oci (137110, 374910, 247b28, 2, 140d4c, 373a08) + ac
    00092d80 Perl_pp_entersub (137110, 247b2c, 80, 0, 247b24, 0) + 5c0
    0008a4dc Perl_runops_standard (137110, ff400000, 0, 800000, 12c, 1cb0b0) + 2c
    0002a458 S_run_body (137110, 1, 137110, 0, ff272a00, 2) + 13c
    0002a0a0 perl_run (137110, 1, 2, ffbff9d4, 134c00, 2) + 8c 0002698c main (2, ffbff9d4, ffbff9e0, 1370f8, ff270100, 0) + b8 0002676c _start (0, 0, 0, 0, 0, 0) + 5c


    What could be the cause of this issue? Compilation was good, so am not sure what might be am missing here?

    Comments / Suggestions please?

    Thanks in advance.

    Regards - Dev
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Any Suggestions please?
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    I hope am posting this issue to correct set of folks? Should I post to some other Forum section on devshed?

    TIA.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,923
    Rep Power
    1225
    I don't have any experience with Oracle, but the first issue I see is that the modules you're building, as well as your perl version is out of date. Have you tried installing the current releases?
  8. #5
  9. !~ /m$/
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    May 2004
    Location
    Reno, NV
    Posts
    4,252
    Rep Power
    1810
    Not only that, but I believe in the original thread you mention building on one machine and then moving the module to another. So I'd like you to be clear about when the modules fail.

    Also, in your build process, make sure to run 'make test' after each supposedly successful compilation and see if every module is actually building correctly.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Actually the requirement is that the compiled oracle library Oracle.so should work with that particular version of perl.

    Reason for old version of modules is because of the dependency matrix, if newer DBD:Oracle is picked then a newer DBI needs to be picked too and this will break the other modules as those were compiled with particular version of DBI.
    Originally Posted by FishMonger
    I don't have any experience with Oracle, but the first issue I see is that the modules you're building, as well as your perl version is out of date. Have you tried installing the current releases?
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Thanks Keath.
    Yes earlier I was doing that wherein was building on one machine and then moving the module to another.

    But now am trying to build on same machine and also test on same machine itself. Difference being in earlier scenario the perl version was different - v5.8.4 built for sun4-solaris-64int, the compilation worked and also able to work successfully on the system itself.

    However now the perl version is different, v5.8.8 built for sun4-solaris-thread-multi-64int. And now compilation works but execution time core dump is thrown.

    Originally Posted by keath
    Not only that, but I believe in the original thread you mention building on one machine and then moving the module to another. So I'd like you to be clear about when the modules fail.

    Also, in your build process, make sure to run 'make test' after each supposedly successful compilation and see if every module is actually building correctly.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Hello Keath, FishMonger, Others,

    While building DBD:Oracle (make) am facing following warnings which I had overlooked:

    gcc -c -I/oracle11g/app/ora11g/product/11.2.0/client_1/rdbms/public -I/opt/myperl/lib/site_perl/5.8.8/sun4-solaris-thread-multi-64int/auto/DBI -D_REENTRANT -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\"1.24\" -DXS_VERSION=\"1.24\" -fPIC "-I/opt/myperl/lib/5.8.8/sun4-solaris-thread-multi-64int/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\"11.2.0.1\" dbdimp.c
    dbdimp.c: In function `ora_db_login6':
    dbdimp.c:468: warning: cast to pointer from integer of different size
    dbdimp.c:482: warning: cast to pointer from integer of different size
    dbdimp.c:492: warning: cast to pointer from integer of different size
    dbdimp.c:496: warning: cast to pointer from integer of different size
    dbdimp.c: In function `dbd_rebind_ph_char':
    dbdimp.c:2347: warning: cast from pointer to integer of different size
    dbdimp.c: In function `dbd_rebind_ph_xml':
    dbdimp.c:2545: warning: cast to pointer from integer of different size

    Could this be an issue which is resulting in run time failure?
    Last edited by Neuron; March 20th, 2013 at 05:45 AM.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,923
    Rep Power
    1225
    I'm not sure but those warnings may be a factor in the core dump. Since I haven't worked with Oracle, I can't say what needs to be done to fix your problem.

    If no one else here has an answer, you may want to post your question on perlmonks.
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Thanks FishMonger.

    One thing to note is when earlier (as replied to Keath) I was using perl version v5.8.4 built for sun4-solaris-64int and CC compiler was picked. No such errors for dbdimp.c was faced that time and things worked correctly at execution time. So these warnings should have something to do with core dump?

    One quick general question here:
    Am I true in saying - the module if compiled with one perl version will not work with other perl version, so any .so files compiled with one perl aren't compatible with the other.
    Hence first need to make sure the perl running script with is the same perl compiled modules with. Is that correct?

    Am compiling with 'perl v5.8.8 built for sun4-solaris-thread-multi-64int' and trying to run with 'perl v5.8.8 built for sun4-solaris'. Do you expect any issues as the version are same but the architectures are different?
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,923
    Rep Power
    1225
    Am compiling with 'perl v5.8.8 built for sun4-solaris-thread-multi-64int' and trying to run with 'perl v5.8.8 built for sun4-solaris'. Do you expect any issues as the version are same but the architectures are different?
    So, you're compiling on a 64bit system but plan on moving it to a 32bit system? If that's the case, then yes I would expect problems.
  22. #12
  23. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    No not really am compiling and running on same system.
    SunOS 5.10 sun4v sparc SUNW,SPARC

    But the perl versions of compile time and execution times are different. The reason am not able to compile with execution time perl is because that perl is not full-fledged and a stripped version.

    Originally Posted by FishMonger
    So, you're compiling on a 64bit system but plan on moving it to a 32bit system? If that's the case, then yes I would expect problems.
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,923
    Rep Power
    1225
    If the architectures are different, then you should expect problems.
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,923
    Rep Power
    1225
    You might want to look at using perlbrew if you need to maintain multiple perl installations.
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2008
    Posts
    38
    Rep Power
    7
    Thanks again FishMonger, the architectures are probable cause here. But one thing which I tried was to remove ‘-DDBI_NO_THREADS’ from Makefile when building with compile time perl, do you think this should make it compatible with execute time perl.

    Although the compilation always had those warning of dbdimp.c, hence could never really verify the above experiment.

    Originally Posted by FishMonger
    You might want to look at using perlbrew if you need to maintain multiple perl installations.

IMN logo majestic logo threadwatch logo seochat tools logo