For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.
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:
.../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) 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
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:
Below are the results of the commands you specified .
InventoryETL: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
dbx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
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
The second command is supposed to be 'dbx InventoryEtl' not 'file InventoryEtl'.