What about problems with loading native library/missing methods: libttJdbc.so, libtten.so - timesten

java.sql.SQLException: Problems with loading native library/missing methods: /home/timesten/TimesTen/tt1122/lib/libttJdbc.so: libtten.so: cannot open shared object file: No such file or directory
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:1794)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:305)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:161)
at java.sql.DriverManager.getConnection(DriverManager.java:620)
at java.sql.DriverManager.getConnection(DriverManager.java:222)
at Test.main(Test.java:15)
Thankyou

Code Example:
try{
String driverName = "com.timesten.jdbc.TimesTenClientDriver"; // "sun.jdbc.odbc.JdbcOdbcDriver"
String Url = "jdbc:timesten:client:dsn=timestendb_1122"; //"jdbc:odbc:timestendb_1122";
if(args.length >= 2){
driverName = args[0];
Url = args[1];
}
System.out.println("driverName=" + driverName);
System.out.println("Url=" + Url);
System.out.println("classPath=" + System.getProperty("java.library.path"));
Class.forName(driverName).newInstance();
// Open a connection to TimesTen
Connection conn = DriverManager.getConnection(Url);
if(conn != null){
System.out.println("okay");
}
else{
System.out.println("fail");
}
conn.close();
} catch (SQLException e) {
e.printStackTrace();
}
odbc.ini config:
[ODBC Data Sources]
timestendb_11221=TimesTen 11.2.2 Driver
[timestendb_1122]
TTC_SERVER=(Host || IP)
UID=Username
PWD=Password
TTC_SERVER_DSN=Cachedb01
Error: java.sql.SQLException: Problems with loading native
library/missing methods: /opt/TimesTen/tt1122/lib/libttJdbcCS.so:
libttclient.so: cannot open shared object file: No such file or
directory
Resolve:
Check if exists:
$ldd /opt/TimesTen/tt1122/lib/libttJdbcCS.so
Screen:
linux-vdso.so.1 => (0x00007fff039b4000)
libttclient.so => not found
libttco.so => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f57d642e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f57d6218000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57d5e58000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57d5c53000)
/lib64/ld-linux-x86-64.so.2 (0x00007f57d6876000)
Check directory timesten client: $ ll /opt/TimesTen/tt1122/lib/libttclient.so
Go to to file to add share lib : sudo vi /etc/ld.so.conf.d/extension.conf -> Add: /opt/TimesTen/tt1122/lib
Check Again
java -Djava.library.path=/opt/TimesTen/tt1122/lib -jar test1.jar
Code Print:
driverName=com.timesten.jdbc.TimesTenClientDriver
Url=jdbc:timesten:client:dsn=timestendb_1122
classPath=/opt/TimesTen/tt1122/lib
java.sql.SQLException: [TimesTen][TimesTen 11.2.2.5.0 CLIENT]Cannot find the requested DSN (timestendb_1122) in ODBCINI, Unable to open /var/TimesTen/tt1122/sys.odbc.ini. Permission denied
Resolve:
export ODBCINI=/etc/odbc.ini (if you used odbc driver)
export ODBCINI=/var/TimesTen/tt1122/sys.odbc.ini (if used timesten driver)
Can be add bash file for user:
nano /home/nhatvd/.bashrc
export ODBCINI=/etc/odbc.ini
$ ldd /opt/TimesTen/tt1122/lib/libttJdbcCS.so
linux-vdso.so.1 => (0x00007fff429fe000)
libttclient.so => /opt/TimesTen/tt1122/lib/libttclient.so (0x00007fd7977ee000)
libttco.so => /opt/TimesTen/tt1122/lib/libttco.so (0x00007fd797520000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd797223000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd79700d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd796c4d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd796a48000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd796748000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd79652b000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fd796310000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd797b12000)
Result:
$ java -Djava.library.path=/opt/TimesTen/tt1122/lib -jar test1.jar
Code Print:
driverName=com.timesten.jdbc.TimesTenClientDriver
Url=jdbc:timesten:client:dsn=timestendb_1122
classPath=/opt/TimesTen/tt1122/lib
okay
DONE.

Related

Mesa glGetString() version differs from glxinfo

In my application I have this piece of code
void showOpenGLInfo()
{
printf("Graphic card vendor: %s\n", glGetString(GL_VENDOR));
printf("Renderer: %s\n", glGetString(GL_RENDERER));
printf("GL version: %s\n", glGetString(GL_VERSION));
printf("GLSL version: %s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));
}
that shows this output on the application log:
Graphic card vendor: Intel
Renderer: Mesa Intel(R) UHD Graphics 600 (GLK 2)
GL version: 4.6 (Compatibility Profile) Mesa 20.3.5
GLSL version: 4.60
I have build Mesa driver 22.0.1 version from source code and glxinfo reports the correct value:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.1
I don't understand this difference, any tip? Debian 11 Bullseye.
Add some OpenGL information:
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 600 (GLK 2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
Add other information based on comments:
ldd /usr/bin/glxinfo
linux-vdso.so.1 (0x00007ffc9c5f6000)
libGLEW.so.2.1 => /lib/x86_64-linux-gnu/libGLEW.so.2.1 (0x00007f3b2a68f000)
libGLU.so.1 => /lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f3b2a61f000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f3b2a598000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3b2a454000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f3b2a311000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f3b2a2fc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3b2a135000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3b29f68000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3b29f4e000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f3b29e96000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f3b29e62000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3b2a760000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3b29e37000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3b29e2f000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3b29e2a000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3b29c24000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f3b29c0d000)
libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f3b29c00000)
ldd my_application
linux-vdso.so.1 (0x00007ffe0092c000)
libc.so.6 => /lib/x86-64-linux-gnu/libc.so.6 (0x00007f1f23936000)
libz.so.1 => /lib/x86-64-linux-gnu/libz.so.1 (0x00007f1f2391a000)
libSDL2-2.0.so.0 => /lib/x86-64-linux-gnu/libSDL2-2.0.so.0 (0x00007f1f237c5000)
libSDL2_image-2.0.so.0 => /lib/x86-64-linux-gnu/libSDL2_image-2.0.so.0 (0x00007f1f237a2000)
libdl.so.2 => /lib/x86-64-linux-gnu/libdl.so.2 (0x00007f1f2379c000)
libm.so.6 => /lib/x86-64-linux-gnu/libm.so.6 (0x00007f1f2364d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f23b4e000)
libasound.so.2 => /lib/x86-64-linux-gnu/libasound.so.2 (0x00007f1f23550000)
libpulse.so.0 => /lib/x86-64-linux-gnu/libpulse.so.0 (0x00007f1f234fb000)
libX11.so.6 => /lib/x86-64-linux-gnu/libX11.so.6 (0x00007f1f233be000)
libXext.so.6 => /lib/x86-64-linux-gnu/libXext.so.6 (0x00007f1f233a9000)
libXcursor.so.1 => /lib/x86-64-linux-gnu/libXcursor.so.1 (0x00007f1f2339c000)
libXinerama.so.1 => /lib/x86-64-linux-gnu/libXinerama.so.1 (0x00007f1f23397000)
libXi.so.6 => /lib/x86-64-linux-gnu/libXi.so.6 (0x00007f1f23383000)
libXrandr.so.2 => /lib/x86-64-linux-gnu/libXrandr.so.2 (0x00007f1f23376000)
libXss.so.1 => /lib/x86-64-linux-gnu/libXss.so.1 (0x00007f1f23371000)
libXxf86vm.so.1 => /lib/x86-64-linux-gnu/libXxf86vm.so.1 (0x00007f1f2336a000)
libwayland-egl.so.1 => /lib/x86-64-linux-gnu/libwayland-egl.so.1 (0x00007f1f23365000)
libwayland-client.so.0 => /lib/x86-64-linux-gnu/libwayland-client.so.0 (0x00007f1f23354000)
libwayland-cursor.so.0 => /lib/x86-64-linux-gnu/libwayland-cursor.so.0 (0x00007f1f23347000)
libxkbcommon.so.0 => /lib/x86-64-linux-gnu/libxkbcommon.so.0 (0x00007f1f23305000)
libpthread.so.0 => /lib/x86-64-linux-gnu/libpthread.so.0 (0x00007f1f232e2000)
libpng16.so.16 => /lib/x86-64-linux-gnu/libpng16.so.16 (0x00007f1f232aa000)
libjpeg.so.8 => /lib/x86-64-linux-gnu/libjpeg.so.8 (0x00007f1f23225000)
libtiff.so.5 => /lib/x86-64-linux-gnu/libtiff.so.5 (0x00007f1f231a4000)
libwebp.so.6 => /lib/x86-64-linux-gnu/libwebp.so.6 (0x00007f1f23138000)
libpulsecommon-13.99.so => /usr/lib/x86-64-linux-gnu/pulseaudio/libpulsecommon-13.99.so (0x00007f1f230b6000)
libdbus-1.so.3 => /lib/x86-64-linux-gnu/libdbus-1.so.3 (0x00007f1f23065000)
libxcb.so.1 => /lib/x86-64-linux-gnu/libxcb.so.1 (0x00007f1f2303b000)
libXrender.so.1 => /lib/x86-64-linux-gnu/libXrender.so.1 (0x00007f1f22e31000)
libXfixes.so.3 => /lib/x86-64-linux-gnu/libXfixes.so.3 (0x00007f1f22e27000)
libffi.so.7 => /lib/x86-64-linux-gnu/libffi.so.7 (0x00007f1f22e1b000)
libzstd.so.1 => /lib/x86-64-linux-gnu/libzstd.so.1 (0x00007f1f22d72000)
liblzma.so.5 => /lib/x86-64-linux-gnu/liblzma.so.5 (0x00007f1f22d49000)
libjbig.so.0 => /lib/x86-64-linux-gnu/libjbig.so.0 (0x00007f1f22b3b000)
libsystemd.so.0 => /lib/x86-64-linux-gnu/libsystemd.so.0 (0x00007f1f22a8a000)
libwrap.so.0 => /lib/x86-64-linux-gnu/libwrap.so.0 (0x00007f1f22a7e000)
libsndfile.so.1 => /lib/x86-64-linux-gnu/libsndfile.so.1 (0x00007f1f22a00000)
libasyncns.so.0 => /lib/x86-64-linux-gnu/libasyncns.so.0 (0x00007f1f227fa000)
libapparmor.so.1 => /lib/x86-64-linux-gnu/libapparmor.so.1 (0x00007f1f227e5000)
librt.so.1 => /lib/x86-64-linux-gnu/librt.so.1 (0x00007f1f227db000)
libXau.so.6 => /lib/x86-64-linux-gnu/libXau.so.6 (0x00007f1f227d3000)
libXdmcp.so.6 => /lib/x86-64-linux-gnu/libXdmcp.so.6 (0x00007f1f227cb000)
liblz4.so.1 => /lib/x86-64-linux-gnu/liblz4.so.1 (0x00007f1f227aa000)
libgcrypt.so.20 => /lib/x86-64-linux-gnu/libgcrypt.so.20 (0x00007f1f2268c000)
libnsl.so.1 => /lib/x86-64-linux-gnu/libnsl.so.1 (0x00007f1f2266f000)
libFLAC.so.8 => /lib/x86-64-linux-gnu/libFLAC.so.8 (0x00007f1f2262f000)
libogg.so.0 => /lib/x86-64-linux-gnu/libogg.so.0 (0x00007f1f22622000)
libvorbis.so.0 => /lib/x86-64-linux-gnu/libvorbis.so.0 (0x00007f1f225f4000)
libvorbisenc.so.2 => /lib/x86-64-linux-gnu/libvorbisenc.so.2 (0x00007f1f22549000)
libresolv.so.2 => /lib/x86-64-linux-gnu/libresolv.so.2 (0x00007f1f2252d000)
libbsd.so.0 => /lib/x86-64-linux-gnu/libbsd.so.0 (0x00007f1f22513000)
libgpg-error.so.0 => /lib/x86-64-linux-gnu/libgpg-error.so.0 (0x00007f1f224ee000)
I found the mistake. My app points to /lib/x86-64-linux-gnu instead of /lib/x86_64-linux-gnu. Now I can use Mesa 22.01 built from source. Many thanks to #genpfault and #derhass for their help

CakePdf on a php5.6 server

The site is on a php5.6 server - shared hosting so installation is done manually using github and php-download.com.
We've chosen to use mpdf and I can create test files by calling it directly.
Our cake site is v3.x.
I've added the pdf extension to routes.php
I've added this to bootstrap.php
Plugin::load('CakePdf',['bootstrap' => true]);
Configure::write('CakePdf', [
'engine' => 'CakePdf.MpdfEngine',
'margin' => [
'bottom' => 15,
'left' => 50,
'right' => 30,
'top' => 45
],
'orientation' => 'portrait',
'download' => true
]);
In my "forms" controller I have 2 functions - they both throw errors on the homepage.
//before the class
use CakePdf\Pdf\CakePdf;
//in the class
function test(){
$this->viewBuilder()->setClassName('CakePdf.Pdf');
$this->viewBuilder()->setLayout('default');
$this->viewBuilder()->options([
'pdfConfig' => [
'engine' => 'CakePdf.MpdfEngine',
'download' => true,
'title' => 'My Form',
'filename' => 'Form1.pdf'
]
]);
}
function test1(){
$pdf_path = WWW_ROOT . 'tmp/tests/'.date('Y-m-d') . DS . 'test1.pdf';
//$CakePdf = new CakePdf();
$CakePdf = new \CakePdf\Pdf\CakePdf\CakePdf();
debug($CakePdf);
exit;
$CakePdf->template('test', 'pdf/default');
$pdf = $CakePdf->output();
$pdf = $CakePdf->write($pdf_path);
}
My error log for /forms/test1 is probably the most useful - in particular the bit where there's the extra 'CakePdf' in the first line
2020-10-12 16:30:12 Error: [Cake\Error\FatalErrorException] Class 'CakePdf\Pdf\CakePdf\CakePdf' not found in /var/www/www.mysite.com/public_html/src/Controller/FormsController.php on line 343
Request URL: /forms/test1.pdf
Stack Trace:
#0 /var/www/www.mysite.com/public_html/vendor/cakephp/cakephp/src/Error/BaseErrorHandler.php(105): Cake\Error\BaseErrorHandler->handleFatalError(1, 'Class 'CakePdf\\...', '/var/www/www.my...', 343)
#1 [internal function]: Cake\Error\BaseErrorHandler->Cake\Error\{closure}()
#2 {main}

How can I see why libstc++ is needed

I'm writing a C application using openGL. All my code is C99 compliant and I'm not using c++ at all. My program links with openGL libs and SDL2.
Running ldd I get:
linux-vdso.so.1 (0x00007ffd456e0000)
libSDL2-2.0.so.0 => /lib64/libSDL2-2.0.so.0 (0x00007fccdb862000)
libGLEW.so.1.13 => /lib64/libGLEW.so.1.13 (0x00007fccdb5d7000)
libGLU.so.1 => /lib64/libGLU.so.1 (0x00007fccdb368000)
libGL.so.1 => /lib64/libGL.so.1 (0x00007fccdb0d9000)
libm.so.6 => /lib64/libm.so.6 (0x00007fccdadcf000)
libc.so.6 => /lib64/libc.so.6 (0x00007fccdaa0c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fccda808000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fccda5ec000)
librt.so.1 => /lib64/librt.so.1 (0x00007fccda3e3000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007fccda0a3000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fccd9d1c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fccd9b04000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fccd98d4000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fccd95eb000)
/lib64/ld-linux-x86-64.so.2 (0x000055a76893d000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fccd93c8000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007fccd91b6000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007fccd8fb1000)
As you can see it links against libstdc++, so I guess another lib need it. How can I check what call is requesting this lib or get more information about the issue?
Thanks.
Run your application as LD_DEBUG=all <cmd-line>, e.g.:
LD_DEBUG=all kwin --version |& grep "needed by"
Outputs:
...
17448: file=libc.so.6 [0]; needed by kwin [0]
17448: file=libxcb-image.so.0 [0]; needed by /lib64/libkwin4_effect_builtins.so.1 [0]
...

xDebug not connecting with Netbeans

I have vm (centos 7, apache, php 5.4). Small test php script works with no problem. When i try to debug it Netbeans (8.0.2 on windows 8.1) shows 'waiting for connection' and nothing more happens. I am using ssh tunnel from vm port 9005 to host port 9005.
xdebug log:
Log opened at 2015-08-16 18:11:22
I: Connecting to configured address/port: localhost:9005.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/project/html/index.php" language="PHP" protocol_version="1.0" appid="55867" idekey="netbeans-xdebug"><engine version="2.3.2"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2015 by Derick Rethans]]></copyright></init>
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
Log closed at 2015-08-16 18:11:24
Result from php -i :
xdebug support => enabled
IDE Key => netbeans-xdebug
xdebug.auto_trace => Off
xdebug.cli_color => 0
xdebug.collect_assignments => Off
xdebug.collect_includes => On
xdebug.collect_params => 0
xdebug.collect_return => Off
xdebug.collect_vars => Off
xdebug.coverage_enable => On
xdebug.default_enable => On
xdebug.dump.COOKIE => no value
xdebug.dump.ENV => no value
xdebug.dump.FILES => no value
xdebug.dump.GET => no value
xdebug.dump.POST => no value
xdebug.dump.REQUEST => no value
xdebug.dump.SERVER => no value
xdebug.dump.SESSION => no value
xdebug.dump_globals => On
xdebug.dump_once => On
xdebug.dump_undefined => Off
xdebug.extended_info => On
xdebug.file_link_format => no value
xdebug.force_display_errors => Off
xdebug.force_error_reporting => 0
xdebug.halt_level => 0
xdebug.idekey => netbeans-xdebug
xdebug.max_nesting_level => 256
xdebug.max_stack_frames => -1
xdebug.overload_var_dump => On
xdebug.profiler_aggregate => Off
xdebug.profiler_append => Off
xdebug.profiler_enable => Off
xdebug.profiler_enable_trigger => Off
xdebug.profiler_enable_trigger_value => no value
xdebug.profiler_output_dir => /tmp
xdebug.profiler_output_name => cachegrind.out.%p
xdebug.remote_autostart => Off
xdebug.remote_connect_back => Off
xdebug.remote_cookie_expire_time => 3600
xdebug.remote_enable => On
xdebug.remote_handler => dbgp
xdebug.remote_host => localhost
xdebug.remote_log => /var/log/xdebug/debug.log
xdebug.remote_mode => req
xdebug.remote_port => 9005
xdebug.scream => Off
xdebug.show_exception_trace => Off
xdebug.show_local_vars => Off
xdebug.show_mem_delta => Off
xdebug.trace_enable_trigger => Off
xdebug.trace_enable_trigger_value => no value
xdebug.trace_format => 0
xdebug.trace_options => 0
xdebug.trace_output_dir => /tmp
xdebug.trace_output_name => trace.%c
xdebug.var_display_max_children => 128
xdebug.var_display_max_data => 2048
xdebug.var_display_max_depth => 3
I tried same config with XDebugClient and it worked -> so it is probably some issues with Netbeans.
remote log with XDebugClient:
Log opened at 2015-08-16 19:43:51
I: Connecting to configured address/port: localhost:9005.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/project/html/index.php" language="PHP" protocol_version="1.0" appid="58314" idekey="netbeans-xdebug"><engine version="2.3.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2015 by Derick Rethans]]></copyright></init>
<- run -i xdc2
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="xdc2" status="break" reason="ok"><xdebug:message filename="file:///var/www/project/html/index.php" lineno="13"></xdebug:message></response>
<- step_out -i xdc10
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="step_out" transaction_id="xdc10" status="stopping" reason="ok"></response>
Log closed at 2015-08-16 19:45:11
in the settings you have
xdebug.remote_host => localhost
you should have the IP address of the remote machine (the one that runs netbeans), and i assume you should have the debuging port opened on windows firewall, so centos can connect back to that port in your netbeans. i haven't done remote debugging on other machines, always local, but this should work.
XDebug sample static ip/single developer:
The IP of the server is 10.0.1.2 with HTTP on port 80
The IDE is on IP 10.0.1.42, so xdebug.remote_host is set to 10.0.1.42
The IDE listens on port 9000, so xdebug.remote_port is set to 9000
The HTTP request is started on the machine running the IDE
Xdebug connects to 10.0.1.42:9000
Debugging runs, HTTP Response provided
Xdebug documentation:
http://xdebug.org/docs/remote

dtrace libc probes on opensolaris

when im trying to do trace getenv function i got:
-bash-4.0#/usr/sbin/dtrace -n 'pid$target:libc:getenv:entry' -p 2017
dtrace: invalid probe specifier pid$target:libc:getenv:entry: probe description
pid2017:libc:getenv:entry does not match any probes
-bash-4.0# /usr/sbin/dtrace -n 'pid$target:libc::entry' -p 2017
dtrace: invalid probe specifier pid$target:libc::entry: probe description pid2017:libc::entry does not match any probes
ldd from myapp:
libz.so.1 => /lib/libz.so.1
libm.so.2 => /lib/libm.so.2
libdl.so.1 => /lib/libdl.so.1
libpthread.so.1 => /lib/libpthread.so.1
libbz2.so.1 => /usr/lib/libbz2.so.1
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsendfile.so.1 => /lib/libsendfile.so.1
libxml2.so.2 => /lib/libxml2.so.2
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libsmbios.so.1 => /usr/lib/libsmbios.so.1
Why is that happening ? Is there any solution which can make libc functions able to trace via dtrace ?
Best regards

Resources