SQL & PL/SQL

Prior to 12.5 the dbx in .../bin was a 32-bit dbx which automatically overlayed the

correct 64-bit dbx on top of itself unless the -xexec32 option was used:

.../bin/dbx           32 bit

.../bin/amd64/dbx     64 bit

You are meant to put .../bin in your $PATH.

Starting with 12.5 we switched the binaries around a bit.

.../bin/dbx           64 bit     # no need for overlay

.../lib/dbx/32/dbx    32 bit     # will be used is -xexec32 is used               

You are, again, meant to put .../bin in your $PATH.

I'm guessing previously you had .../bin/amd64 in your path and then it vanished

so you put .../lib/dbx/32 in your path?

Or somehow the installation went awry?

Thanks for clarifying , however I did have the path setup and the path is definitely pointing to the right bin directory. Not sure if it has anything to do with me running this on Ubuntu 16.04 , see below . There is a reference to a 'disassembler_version: not found'

$ which dbx

/opt/developerstudio12.5/bin/dbx

jb27617@Office:~/LODS/src/wwopsbig/apps/r12/SupplyChainExposure/InventoryEtl/bin$ dbx -I ../src InventoryEtl

dbx: 32-bit dbx can't debug 64-bit app 'InventoryEtl'

disassembler_version: not found

error at line 1 of file './.dbxrc'

(dbx)

Even on Linux the following should be true:

.../bin/dbx           64 bit     # no need for overlay

.../lib/dbx/32/dbx    32 bit     # will be used is -xexec32 is

Can you use the 'file' command to verify the bitness of these dbx's

in your installation?

I downloaded and installed the "tarball"s from the download site and

they seem to be correct. If you used the RPM packages maybe there's

a mistake in their content.

Instead of relying on 'which' and $PATH experiment with absolute

pathnames first.

---------------------------------------------------------------------

'disassembler_version' is the name of a 'dbxenv' (Issue "help dbxenv"

at the dbx commandline). One gets and sets dbxenvs like this:

(dbx-0) dbxenv disassembler_version                                         
autodetect
(dbx-0) dbxenv disassembler_version v9
(dbx-0) dbxenv disassembler_version  
v9
(dbx-0) disassembler_version v8     # forgot 'dbxenv' 
disassembler_version: not found     # looks familiar?

So, What's on line 1 of "./.dbxrc"?

You are right about the 'dissembler_version' there was a local .dbxrc file in the directory that had that as the only entry .

This is the out put from the file command. Which looks like it would indicated that it is 64 bit ?. I'll try to re-install to see if that changes anything, as I still get that message.

jb27617@Office:/opt/developerstudio12.5/bin$ file dbx

dbx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped

Thanks

Johan

Let's not quite reinstall things yet because 'file dbx' said that it's a 64-bit executable

and that doesn't indicate a bad install.

Now the puzzle is, why, if you're executing a 64-bit dbx, is

it saying: dbx: 32-bit dbx can't debug 64-bit app.

So I urge you again to use absolute pathnames and see what happens:

     /opt/developerstudio12.5/bin/dbx InventoryEtl

vs

     /opt/developerstudio12.5/lib/dbx/32/dbx InventoryEtl

Wild idea: You have an alias/function "dbx=dbx -xexec32"

As an FYI I installed the tar binaries on an environment at work Ubuntu 14.04 and it worked fine. I'll have to check your suggestion later on this evening on the 16.04. Another thing I forgot to say was that I used a symbolic link to change the provided linker (ld) to point to  the system version /usr/bin/ld  as I always got an error on the Studio version.  I doubt that has a bearing as the executable works fine ?

Here are the dbxenv setting after I run dbx against the executable

$ dbx -I ../src InventoryEtl

dbx: 32-bit dbx can't debug 64-bit app 'InventoryEtl'

(dbx) dbxenv

array_bounds_check       on

c_array_op               off

core_lo_pathmap          off

ddl_version              3

debug_file_directory     /usr/lib/debug

disassembler_version     autodetect

event_safety             on

filter_max_length        512

fix_verbose              off

follow_fork_inherit      off

follow_fork_mode         parent

follow_fork_mode_inner   unset

gui_error_verbose        off

gui_show_main            on

input_case_sensitive     autodetect

language_mode            autodetect

macro_expand             on

macro_source             skim_unless_compiler

mi_mode                  off

mt_resume_one            auto

mt_scalable              off

mt_sync_tracking         off

output_auto_flush        on

output_base              automatic

output_class_prefix      on

output_data_member_only  off

output_dynamic_type      off

output_inherited_members off

output_list_size         10

output_log_file_name     /tmp/dbx.log.21784.1000.0

output_max_object_size   4096

output_max_string_length 4096

output_no_literal        off

output_pretty_print      off

output_pretty_print_fallback on

output_pretty_print_mode call

output_short_file_name   on

overload_function        on

overload_operator        on

pop_auto_destruct        on

proc_exclusive_attach    on

proc_track_cwd           off

rtc_auto_continue        off

rtc_auto_suppress        on

rtc_biu_at_exit          on

rtc_error_limit          1000

rtc_error_log_file_name  /tmp/dbx.errlog.21784.1000.3

rtc_error_stack          off

rtc_inherit              off

rtc_mel_at_exit          on

run_autostart            off

run_io                   stdio

run_pty                 

run_quick                off

run_savetty              off

run_setpgrp              off

scope_global_enums       off

scope_look_aside         on

session_log_file_name   

show_static_members      on

stack_find_source        on

stack_max_size           100

stack_verbose            on

step_abflow              stop

step_events              off

step_granularity         statement

suppress_startup_message 3.01

symbol_info_compression  on

trace_speed              0.50

vdl_mode                 lisp

vdl_version              2

(dbx)

The linker has no bearing on this.

The list of dbxenv's doesn't help diagnose the issue.

What _will_ is specifically the following:

$ file /opt/developerstudio12.5/bin/dbx

$ /opt/developerstudio12.5/bin/dbx InventoryEtl

$ file /opt/developerstudio12.5/lib/dbx/32/dbx

$ /opt/developerstudio12.5/lib/dbx/32/dbx InventoryEtl

Hi , sorry for the delay..

The problem seems to be related to Ubuntu 16.04. Everything works fine on Ubuntu 14.04. To verify I installed this all on a completely different system with 16.04 and I get the exact same problem. Could it be related to the libraries installed. I.e. dbx is trying to load an i386 library where the 64 bit version is missing on 16.04 ?.

Although when I compare the 'ldd dbx' results across 12.4 and 12.5 both on Ubuntu 14.04 and 16.04 they look nearly identical outside of the version of the demangle library ?

With respect your above question it all returns what you would expect ?

The fact that it works on one version of ubuntu but not another, at this moment, does not

help diagnose the issue.

Speculation about shared libraries doesn't help diagnose the issue.

What _will_ help is specifically the following:

$ file /opt/developerstudio12.5/bin/dbx

$ /opt/developerstudio12.5/bin/dbx InventoryEtl

$ file /opt/developerstudio12.5/lib/dbx/32/dbx

$ /opt/developerstudio12.5/lib/dbx/32/dbx InventoryEtl

Below are the results of the commands you specified .

Thanks

$ file /opt/developerstudio12.5/bin/dbx

dbx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped

$ /opt/developerstudio12.5/bin/dbx InventoryEtl

InventoryETL: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

$ file /opt/developerstudio12.5/lib/dbx/32/dbx

dbx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped

$ /opt/developerstudio12.5/lib/dbx/32/dbx InventoryEtl

dbx: 32-bit dbx can't debug 64-bit app 'InventoryETL'

For information about new features see `help changes'

To remove this message, put `dbxenv suppress_startup_message 8.1' in your .dbxrc

(dbx)

The second command is supposed to be 'dbx InventoryEtl' not 'file InventoryEtl'.