How to use uprobe to trace OpenJDK HotSpot source code? - java-8

I try to follow the instructions from link
In this example,
Tracing func_abc() in my test program, and including user-level stacks:
# ./uprobe -s p:/root/func_abc:func_c
Tracing uprobe func_c (p:func_c /root/func_abc:0x4f4). Ctrl-C to end.
func_abc-25394 [000] d... 19603250.054040: func_c: (0x4004f4)
func_abc-25394 [000] d... 19603250.054056: <user stack trace>
=> <00000000004004f4>
=> <0000000000400527>
=> <0000000000400537>
=> <00007fca9f0e376d>
func_abc-25394 [000] d... 19603251.054250: func_c: (0x4004f4)
func_abc-25394 [000] d... 19603251.054266: <user stack trace>
=> <00000000004004f4>
=> <0000000000400527>
=> <0000000000400537>
=> <00007fca9f0e376d>
^C
Ending tracing...
I want to probe function minor_collection_begin but it shows ERROR: missing symbol.
root#wxf:/home/wxf/perf-tool/perf-tools/bin# ./uprobe -s p:/home/wxf/9dev/build/linux-x86_64-normal-server-slowdebug/jdk/bin/java:AdaptiveSizePolicy::minor_collection_begin
ERROR: missing symbol "minor_collection_begin" in /home/wxf/9dev/build/linux-x86_64-normal-server-slowdebug/jdk/bin/java
root#wxf:/home/wxf/perf-tool/perf-tools/bin# ./uprobe -s p:/home/wxf/9dev/build/linux-x86_64-normal-server-slowdebug/jdk/bin/java:minor_collection_begin
ERROR: missing symbol "minor_collection_begin" in /home/wxf/9dev/build/linux-x86_64-normal-server-slowdebug/jdk/bin/java
I search a lot and find it is related to libjvm.so. However, I don't know what to do next.
wxf#wxf:/home/wxf/adjustableMaxHeapSize_9jdk_prj/9dev$ find -name "libjvm.so"
./build/linux-x86_64-normal-server-slowdebug/support/modules_libs/java.base/server/libjvm.so
./build/linux-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/gtest/libjvm.so
./build/linux-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.so

C++ symbols are mangled in binary objects. You won't find minor_collection_begin. The mangled symbol name for void AdaptiveSizePolicy::minor_collection_begin() is
_ZN18AdaptiveSizePolicy22minor_collection_beginEv

Related

Replace linux dynamic loader in bazel run/test execution

I have an issue writing a custom wrapper around go_test from rules_go:
My situation: I have a set of precompiled libraries (.so) for Fedora that I want to link against go code using cgo. This part works beautifully. The resulting binaries run correctly on Fedora.
I even have declared all of the libraries as dependencies correctly and they show up in the runfiles of my go_binary outputs.
The precompiled .so files also include glibc from fedora (this is required since the other shared libraries depend on this version of the glibc) and ld-linux-x86-64.so.2 from Fedora.
How would I write a wrapper around go_test that uses the vendored ld from Fedora as a binary and passes the original go binary path as the first argument?
Additional info:
All of the libraries are accessible via the runfiles and findable via the ELF runpath. It's only ld itself that is selected incorrectly:
$ readelf -a bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs:$ORIGIN/initserver_test.runfiles/__main__/_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs]
$ ldd bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
/lib64/ld-linux-x86-64.so.2 (0x00007f944795d000)
linux-vdso.so.1 (0x00007fff66347000)
libargon2.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libargon2.so.1 (0x00007f9447952000)
libblkid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libblkid.so.1 (0x00007f9447919000)
libc.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libc.so.6 (0x00007f944773c000)
libcrypto.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcrypto.so.3 (0x00007f9447312000)
libcryptsetup.so.12 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcryptsetup.so.12 (0x00007f9447294000)
libdevmapper.so.1.02 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libdevmapper.so.1.02 (0x00007f9447238000)
libgcc_s.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libgcc_s.so.1 (0x00007f9447218000)
libjson-c.so.5 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libjson-c.so.5 (0x00007f9447205000)
libm.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libm.so.6 (0x00007f9447123000)
libpcre2-8.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpcre2-8.so.0 (0x00007f9447086000)
libpthread.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpthread.so.0 (0x00007f9447081000)
libselinux.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libselinux.so.1 (0x00007f9447054000)
libssl.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libssl.so.3 (0x00007f9446fb1000)
libudev.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libudev.so.1 (0x00007f9446f81000)
libuuid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libuuid.so.1 (0x00007f9446f78000)
libz.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libz.so.1 (0x00007f9446f5e000)
$ bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 --list bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
/lib64/ld-linux-x86-64.so.2 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 (0x00007f637dec7000)
linux-vdso.so.1 (0x00007ffd2e1e8000)
libargon2.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libargon2.so.1 (0x00007f637debc000)
libblkid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libblkid.so.1 (0x00007f637de83000)
libc.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libc.so.6 (0x00007f637dca6000)
libcrypto.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcrypto.so.3 (0x00007f637d87c000)
libcryptsetup.so.12 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcryptsetup.so.12 (0x00007f637d7fe000)
libdevmapper.so.1.02 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libdevmapper.so.1.02 (0x00007f637d7a2000)
libgcc_s.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libgcc_s.so.1 (0x00007f637d782000)
libjson-c.so.5 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libjson-c.so.5 (0x00007f637d76f000)
libm.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libm.so.6 (0x00007f637d68d000)
libpcre2-8.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpcre2-8.so.0 (0x00007f637d5f0000)
libpthread.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpthread.so.0 (0x00007f637d5eb000)
libselinux.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libselinux.so.1 (0x00007f637d5be000)
libssl.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libssl.so.3 (0x00007f637d51b000)
libudev.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libudev.so.1 (0x00007f637d4eb000)
libuuid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libuuid.so.1 (0x00007f637d4e2000)
libz.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libz.so.1 (0x00007f637d4c8000)
When using bazel run or bazel test on Ubuntu, my host ld-linux-x86-64.so.2 is used and I get a segfault. This is due to the hardcoded path to the interpreter (LD) embedded in the go binary and because ld and libc have to match:
readelf -p .interp bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
Segmentation fault (core dumped)
The same works if I execute fedoras ld-linux-x86-64.so.2 directly and give it the path to the go binary as an argument (this is equivalent to setting the interpreter in the elf header to the absolute path of the location of the fedora ld on my host).
bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test.runfiles/__main__/_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
PASS

LLDB symbol dumps

I'm trying to understand the following symbol dump from the LLDB shell
(lldb) target create --no-dependents '9.0/Symbols/Library/Application Support/WatchKit/WK'
Current executable set to '9.0/Symbols/Library/Application Support/WatchKit/WK' (armv7k).
(lldb) image list
[ 0] 675ED1EB-BAA0-3453-B7B1-3E69310F40FD 0x00004000 9.0/Symbols/Library/Application Support/WatchKit/WK
(lldb) image dump symtab
Dumping symbol table for 1 modules.
Symtab, file = 9.0/Symbols/Library/Application Support/WatchKit/WK, num_symbols = 6:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 0 Code 0x0000000000007fcc 0x0000000000000030 0x001e0000 stub helpers
[ 1] 1 X Data 0x0000000000004000 0x0000000000003fcc 0x000f0010 _mh_execute_header
[ 2] 2 X ReExported 0x000b0000 main -> /System/Library/PrivateFrameworks/SockPuppetGizmo.framework/SockPuppetGizmo`_SPApplicationMain
[ 3] 3 X Undefined 0x0000000000000000 0x0000000000000000 0x00010100 _SPApplicationMain
[ 4] 4 X Undefined 0x0000000000000000 0x0000000000000000 0x00010500 dyld_stub_binder
[ 5] 5 S Trampoline 0x0000000000007ffc 0x0000000000000004 0x00000000 main
Most of it I can kinda understand because there are addresses and sizes associated with the symbol but some of them I don't understand. In this case there are 2 "undefined" symbols with 0x00 for the address and 0x00 for the size. My question is what do those symbols mean? Does that mean they are resolved at runtime and I really shouldn't be concerned about them when trying to make sense of things in crash logs?
Your guess is correct, Undefined symbols are symbols that one binary wants to use from some other binary. They will get fixed up by the loader when your program runs.
So for instance, if you write the standard "hello world" program, the main binary will have an Undefined symbol for "printf". BTW, these are the same as the symbols of type U that you see in the output of nm.

CFE syntax errors

Trying to write a cfengine3 promise that will take an entire directory and move it down one level.
I've used my policy hub to distribute the promise, but I've not yet folded it into my active promise.cf
Here's the promise:
body common control
{
bundlesequence => { dirstructure };
}
#Find out by existance of directories if filesystem is old structure or new
#Set classes for each instance. If old, copy down one level.
#If new file system already, pat yourself on the back
bundle agent dirstructure
{
classes:
"oldFILEstructure"expression => isdir("/old/dir/structure/");
"newFILEstructure" expression => isdir("/new/dir/structure/");
reports:
oldFILEstructure::
"system has old file structure..";
newFILEstructure::
"system has new file structure..";
methods:
oldFILEstructure::
"migratedirectories" usebundle => movedirectories
}
bundle agent movedirectories
{
files:
"/new/dir/"
copy_from => local_cp ("/old/dir/structure/.");
depth_search => recurse ("inf");
}
I've used this "isdir" source and this example for local_cp, both from CFE to base the promise on.
When invoked, I get the following error output and I'm trying to figure out why.
:/var/cfengine/inputs/standalone# cf-agent --no-lock --inform --file ./file_structure.cf
./file_structure.cf:41:12: error: syntax error
depth_search => recurse ("inf");
^
./file_structure.cf:41:12: error: Expected promiser string, got 'depth_search'
depth_search => recurse ("inf");
^
./file_structure.cf:41:15: error: Expected ';', got '=>'
depth_search => recurse ("inf");
^
./file_structure.cf:41:23: error: Expected promiser string, got 'recurse'
depth_search => recurse ("inf");
^
./file_structure.cf:41:25: error: Expected ';', got '('
depth_search => recurse ("inf");
^
./file_structure.cf:41:31: error: Expected ';', got ')'
depth_search => recurse ("inf");
^
./file_structure.cf:41:32: error: Expected promiser string, got ';'
depth_search => recurse ("inf");
^
./file_structure.cf:42:1: error: Expected ';', got '}'
}
files:
"/new/dir/"
copy_from => local_cp ("/old/dir/structure/.");
depth_search => recurse ("inf");
}
You have an extra semicolon at the end of the copy_from line.
A semicolon ; identifies the end of a promise. Try switching the semicolon at the end of the copy_from line to a comma ,.
files:
"/new/dir/"
copy_from => local_cp ("/old/dir/structure/."),
depth_search => recurse ("inf");
}
Additionally you may want to check out the transformer attribute.
It may or may not be a good use for your case.\
bundle agent example
{
files:
"/old/dir/structure" -> { "jira:EXAMPLE-1234" }
transformer => "/bin/mv /old/dir/structure /new/dir/structure",
comment => "The standard is to use the new location because x, y, z. Bad thing Q or U might happen if this is not managed properly.";
}

LazReport doesn't work on second machine

I have two computers - Ubuntu 12.04 + Lazarus. Let's call them A and B.
I develop a program on A. It works fine.
I run the same program on B using Lazarus and it works fine.
Then I make a compiled program (binary) on A and try it on B. Now the problem starts.
Everything works fine except that none of the reports (LazReport) appear. There's no error. Just no response. The program continues without a crash but just no response. How is this possible?
Clues:
On machine A and B, I installed the software (Lazarus) as the default admin user.
On machine B, I have another user account but this is a standard user.
On machine B, I installed LazReport component on Lazarus using the standard user account. So I suspect a permissions issue.
Then I removed the LazReport component on Lazarus from machine B and reinstalled it a second time. But this time I ran it as admin like this gksu -u ADMIN -w startlazarus but still no change.
Please advice how I may solve this problem.
My restriction:
I must be able to do this using the standard account and not ADMIN. Is this even possible?
Thanks!
EDIT: here's the output of ldd:
linux-gate.so.1 => (0xb76f3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76c3000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb758f000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb756d000)
libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xb7105000)
libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 (0xb7056000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb7007000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6f0e000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb6f0a000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb6f05000)
libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 (0xb6ebb000)
libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xb6df0000)
libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb6dd0000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6dca000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6c20000)
/lib/ld-linux.so.2 (0xb76f4000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6bff000)
libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6aa8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6a7c000)
libpangocairo-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb6a6e000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6a68000)
libpangoft2-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6a3c000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6a08000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb69f6000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb69eb000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xb69e7000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb69d7000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb69ce000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb69c3000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xb69be000)
libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb69ba000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb69b3000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6977000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb696e000)
libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb68d5000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb683b000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6811000)
libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xb680d000)
libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xb6803000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb67ec000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb67e8000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb67e1000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb67c2000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb67aa000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb677f000)
They appear IDENTICAL on machines A and B except that the hex number within brackets is different. Apart from that, it's the same line to line.
EDIT: More info - new findings...
I opened a terminal. Then ran Nautilus. Then I run my binary and when trying the report, I got this error in the terminal:
[WARNING] SetAlphaBlend called without handle for
frProgressForm(TfrProgressForm)
I have no clue but I believe this is the bug. I have no form like the one mentioned either.
Apparently, as I discovered much later, the reports didn't work outside of the development folder although the rest of the application did.
The solution was to simply copy the report files (.lrf) and put it into the destination folder that contained the binary.

Firefox 3.6 under debian squeeze

While I want to start my Firefox 3.6 which I installed under /opt/firefox/
I have the Following Error:
[root#box]: ./firefox-bin
./firefox-bin: error while loading shared libraries: libxul.so: cannot open shared object file: No such file or directory
Here is my ldd output:
ldd firefox-bin
linux-gate.so.1 => (0xf77cf000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf779e000)
libxul.so => not found
libxpcom.so => not found
libmozalloc.so => not found
libplds4.so => /usr/lib32/libplds4.so (0xf779a000)
libplc4.so => /usr/lib32/libplc4.so (0xf7796000)
llibnspr4.so => /usr/lib32/libnspr4.so (0xf7762000)
libdl.so.2 => /lib32/libdl.so.2 (0xf775d000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7668000)
libm.so.6 => /lib32/libm.so.6 (0xf7642000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7624000)
libc.so.6 => /lib32/libc.so.6 (0xf74dd000)
/lib/ld-linux.so.2 (0xf77d0000)
The file is there an all the others too:
[root#box]: locate libxul
/opt/firefox/libxul.so
So they are 3 files missing. Can you help to get me them?
EDIT:
With the short fix:
export LD_LIBRARY_PATH=/opt/firefox/
I get the same error with ./firefox-bin
./firefox-bin: error while loading shared libraries: libpangoft2-1.0.so.0: cannot open shared object file: No such file or directory
You should start it with /opt/firefox/firefox
Looks like there is something wrong with you package mananger ...
ldd firefox-bin
libxul.so => not found
...
locate libxul
/opt/firefox/libxul.so
this part can be solved with
export LD_LIBRARY_PATH=/opt/firefox/
..../firefox-bin
or
LD_LIBRARY_PATH=/opt/firefox/ ..../firefox-bin
Try:
sudo apt-get install ia32-libs-gtk

Resources