Re: Debian sid, PHP cli, xdebug, set_error_handler, mysql_list_dbs, throw = Segmentation fault
On 19.03.2013 21:41, Jerry Stuckle wrote:
On 3/19/2013 3:08 PM, Sven Uhlig wrote:
On 17.03.2013 23:40, Jerry Stuckle wrote:
On 3/17/2013 2:54 PM, Sven Uhlig wrote:
On 17.03.2013 16:01, Jerry Stuckle wrote:
On 3/17/2013 9:20 AM, Sven Uhlig wrote:
The following PHP code exits in segmentation fault.
?php
function error_handler() {
throw new Exception;
}
set_error_handler('error_handler');
mysql_list_dbs();
?
No segmentation fault if I do either of these things:
1) disable xdebug
2) don't set_error_handler
3) don't throw exception
4) throw exception after mysql_list_dbs but outside of error_handler
$ php -v
PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
# uname -a
Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
Impossible to tell from the (lack of) information you supplied.
What do you need?
Well, if it happened to me, I'd get a dump of the problem, preferably
with a debug version of the binaries, and a trace leading up to the
problem. Then I'd dig in and see where the problem lies.
Because I am no C developer, I have no idea where to look for the cause
of the problem. All I can do is to help someone else fixing the code of
xdebug/php. But I am really not the right person to do this.
I'm not sure about anyone else on this list, but unfortunately I don't
have the time it would take to duplicate your environment then try to
duplicate your problem.
I understand you're not a C programmer - which is why I suggested you
start with the developer of xdebug. It's where I would start if I had
this problem.
Jerry, sorry. I totally got you wrong before. I tought you wanted me to
fix the problem...
I have forwarded the bug report to xdebug
http://bugs.xdebug.org/view.php?id=936
Best regards
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5149df1d.8020...@web.de
Re: Debian sid, PHP cli, xdebug, set_error_handler, mysql_list_dbs, throw = Segmentation fault
On 17.03.2013 23:40, Jerry Stuckle wrote:
On 3/17/2013 2:54 PM, Sven Uhlig wrote:
On 17.03.2013 16:01, Jerry Stuckle wrote:
On 3/17/2013 9:20 AM, Sven Uhlig wrote:
The following PHP code exits in segmentation fault.
?php
function error_handler() {
throw new Exception;
}
set_error_handler('error_handler');
mysql_list_dbs();
?
No segmentation fault if I do either of these things:
1) disable xdebug
2) don't set_error_handler
3) don't throw exception
4) throw exception after mysql_list_dbs but outside of error_handler
$ php -v
PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
# uname -a
Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
Impossible to tell from the (lack of) information you supplied.
What do you need?
Well, if it happened to me, I'd get a dump of the problem, preferably
with a debug version of the binaries, and a trace leading up to the
problem. Then I'd dig in and see where the problem lies.
Because I am no C developer, I have no idea where to look for the cause
of the problem. All I can do is to help someone else fixing the code of
xdebug/php. But I am really not the right person to do this.
Here is the backtrace of gdb after I have installed php5-dbg.
#0 _zend_mm_alloc_int (heap=0xdb92b0, size=32) at
/tmp/buildd/php5-5.4.4/Zend/zend_alloc.c:1906
#1 0x0069eeda in zend_error (type=8192, format=0xa77fdf %s)
at /tmp/buildd/php5-5.4.4/Zend/zend.c:1105
#2 0x0063d376 in php_verror (docref=0xdb84c0
x\255\377\377\377\177,
params=0x1 Address 0x1 out of bounds, type=8192, format=0x1
Address 0x1 out of bounds, args=0x1)
at /tmp/buildd/php5-5.4.4/main/main.c:853
#3 0x0063d79e in php_error_docref0 (docref=0xdb92b0 \001,
type=32,
format=0x1 Address 0x1 out of bounds) at
/tmp/buildd/php5-5.4.4/main/main.c:865
#4 0x745f86e1 in ?? () from /usr/lib/php5/20100525/mysql.so
#5 0x74a2aedc in xdebug_execute_internal
(current_execute_data=0x74f26060, return_value_used=0)
at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1483
#6 0x00746a3e in zend_do_fcall_common_helper_SPEC
(execute_data=0x74f26060)
at /tmp/buildd/php5-5.4.4/Zend/zend_vm_execute.h:644
#7 0x00700447 in execute (op_array=0x74f592f0) at
/tmp/buildd/php5-5.4.4/Zend/zend_vm_execute.h:410
#8 0x74a2aa81 in xdebug_execute (op_array=0x74f592f0)
at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1391
#9 0x006a028e in zend_execute_scripts (type=8,
retval=0x74f592b8, file_count=3)
at /tmp/buildd/php5-5.4.4/Zend/zend.c:1279
#10 0x0063f863 in php_execute_script (primary_file=0x75b44ec0)
at /tmp/buildd/php5-5.4.4/main/main.c:2473
#11 0x007491b3 in do_cli (argc=0, argv=0x7fffe8f1) at
/tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:988
#12 0x0043110a in main (argc=32767, argv=0xdb9210) at
/tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:1361
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5148b7a9.3010...@web.de
Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable
On 17.03.2013 02:53, Clive Standbridge wrote: The reasons seems to be my setup of the system. Debian runs in a VirtualBox environment, headless and w/o X server. I use ssh to connect to the system. (putty) I use X forwarding to run X applications on the system. The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth. I'm pretty sure that the value of DISPLAY means you are using a traditional X connection, and not actually using the X forwarding over ssh. ssh would set DISPLAY to localhost:10 or similar. That is so true! I have no idea why I have overlooked that fact. You will need to remove any setting of DISPLAY from your shell's startup files. Done. I guess at some point I wanted to be smart and expected that using a direct connection was quicker than X11Forwarding. mea culpa Make sure your /etc/ssh/sshd_config contains a line: X11Forwarding yes $ grep X11 /etc/ssh/sshd_config X11Forwarding yes X11DisplayOffset 10 Then connect from Putty without X forwarding. DISPLAY should not be set on the Debian machine. $ echo $DISPLAY|wc --words 0 Then connect from Putty with X forwarding. DISPLAY should be localhost:10 or similar. $ echo $DISPLAY localhost:10.0 I hope this helps. It actually does. Even if I keep X forwarding enabled and $DISPLAY set, su is a lot faster now, good enough for me - problem solved. Thank you very much for your help! :) I think the reason why it is faster is that $DISPLAY is localhost with dbus running. There is no Timeout in strace but only seemingly successfull calls to the FD of the dbus socket. Also if I do /etc/init.d/dbus stop su is even faster (read instant.) And interestingly virt-manager still works without dbus. (virt-manager is the package that also installed dbus) Sven. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5145988d.2050...@web.de
Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable
On 17.03.2013 03:12, Bob Proulx wrote: Sven Uhlig wrote: Bob Proulx wrote: The problem is that su takes 25 seconds before it succeeds. That sounds like a DNS timeout. If you do a dns lookup of your systems hostname does it respond? # nslookup baldur ** server can't find baldur: NXDOMAIN # nslookup baldur.asgard ** server can't find baldur.asgard: NXDOMAIN Unfortunately nslookup only looks at DNS. It is a DNS tool and does not follow /etc/nsswitch.conf for looking at other locations such as the /etc/hosts file. It is the reason I use the libc tool 'getent' to use the libc lookup routine and do whatever is configured. getent baldur.asgard That is why I used C's getnameinfo(). How should getent work? # getent baldur.asgard Unknown database: baldur.asgard # getent -V getent (Debian EGLIBC 2.13-38) 2.13 Nevermind, my problem is solved, see mail by Clive Standbridge. :) # ping baldur PING baldur.asgard (127.0.1.1) 56(84) bytes of data. See that ping does do the lookup and does find the address okay. But although I know that many people use ping for a lookup tool that is really only a side effect of the primary purpose of ping. I know but it is very convenient. That long delay in sudo with dns broken is why I suspected a problem with your 'su' delay and was thinking it might be similar. It is a network thing. $DISPLAY was set to 10.0.2.2:0 where it should have been localhost:10.0 In the output of strace I can see that /something/ happens with libnss, so DNS lookup. Another brainstorm idea. Do you have libnss-mdns installed? As an experiment try removing it. I doubt you are using it. You can always install it again. # apt-get purge libnss-mdns Package 'libnss-mdns' is not installed, so not removed I wish I could be more help. Hopefully someone knowledgeable about dbus will have help with a solution for it. Well, no help regarding dbus. But regarding X11Forwarding. Thank you for your input! Sven. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514598ab.7020...@web.de
Debian sid, PHP cli, xdebug, set_error_handler, mysql_list_dbs, throw = Segmentation fault
Hello again,
this time I write to this list to report a bug, a segmentation fault.
Couldn't find any lead to this bug anywhere else. And because of so many
related packages, I dont know where to post it. Did I find the right place?
The following PHP code exits in segmentation fault.
?php
function error_handler() {
throw new Exception;
}
set_error_handler('error_handler');
mysql_list_dbs();
?
No segmentation fault if I do either of these things:
1) disable xdebug
2) don't set_error_handler
3) don't throw exception
4) throw exception after mysql_list_dbs but outside of error_handler
As I only wanted to use mysql_list_dbs() for testing purposes I don't
need an alternative solution. I know that this function is deprecated in
PHP5.4.
Some technical details:
$ strace php test.php 21 |tail -n 3
read(3, \7\0\0\2\0\0\0\2\0\0\0, 16384) = 11
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
$ php -v
PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
$ cat /etc/apt/sources.list
deb http://ftp2.de.debian.org/debian/ sid main non-free
deb-src http://ftp2.de.debian.org/debian/ sid main non-free
# (apt-get update apt-get upgrade)|tail -n 1
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# uname -a
Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
Best regards
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5145c329.6060...@web.de
Re: Debian sid, PHP cli, xdebug, set_error_handler, mysql_list_dbs, throw = Segmentation fault
On 17.03.2013 16:01, Jerry Stuckle wrote:
On 3/17/2013 9:20 AM, Sven Uhlig wrote:
The following PHP code exits in segmentation fault.
?php
function error_handler() {
throw new Exception;
}
set_error_handler('error_handler');
mysql_list_dbs();
?
No segmentation fault if I do either of these things:
1) disable xdebug
2) don't set_error_handler
3) don't throw exception
4) throw exception after mysql_list_dbs but outside of error_handler
As I only wanted to use mysql_list_dbs() for testing purposes I don't
need an alternative solution. I know that this function is deprecated in
PHP5.4.
Some technical details:
$ strace php test.php 21 |tail -n 3
read(3, \7\0\0\2\0\0\0\2\0\0\0, 16384) = 11
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
$ php -v
PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
$ cat /etc/apt/sources.list
deb http://ftp2.de.debian.org/debian/ sid main non-free
deb-src http://ftp2.de.debian.org/debian/ sid main non-free
# (apt-get update apt-get upgrade)|tail -n 1
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# uname -a
Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
Impossible to tell from the (lack of) information you supplied.
What do you need?
However,
personally, I would start with xdebug. I've seen more problems with it
than anything else in your list. I finally got rid of it.
As stated above, disabling xdebug does the trick. But that cannot be a
permanent solution and I think a segmentation fault is always worth fixing.
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5146115b.8040...@web.de
Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable
On 16.03.2013 05:45, Bob Proulx wrote:
The problem is that su takes 25 seconds before it succeeds.
That sounds like a DNS timeout. If you do a dns lookup of your
systems hostname does it respond?
# nslookup localhost
Name: localhost
Address: 127.0.0.1
# nslookup 127.0.0.1
1.0.0.127.in-addr.arpa name = localhost.
# nslookup baldur
** server can't find baldur: NXDOMAIN
# nslookup baldur.asgard
** server can't find baldur.asgard: NXDOMAIN
# ping baldur
PING baldur.asgard (127.0.1.1) 56(84) bytes of data.
Look in /etc/hosts and look for (at least) these lines:
# grep 127. /etc/hosts
127.0.0.1 localhost
127.0.1.1 baldur.asgard baldur
Because PAM often logs the hostname to the system log and does
other such DNS lookups.
Can I disable reverse DNS lookup?
Using strace I think I identified the problem:
connect(4, {sa_family=AF_FILE,
path=/var/run/dbus/system_bus_socket}, 33) = 0
... poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout)
25.028989
I can skip the timeout if I do either of these two things:
Solution 1) run X server on 10.0.2.2 (Xming) Solution 2) unset
$DISPLAY
If you dns lookup 10.0.2.2 does it resolve? Quickly or after a
longer timeout?
# nslookup 10.0.2.2
** server can't find 2.2.0.10.in-addr.arpa.: NXDOMAIN
# ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
# ping wotan
ping: unknown host wotan
C's getnameinfo() returns: Name or service not known
But as it is a private IP, why should there be a DNS? Wouldnt everyone
have the same problem if they dont set up their own BIND or hosts file?
I have added the remote hostname to /etc:
# grep wotan /etc/hosts
10.0.2.2 wotan.asgard wotan
Of course I only get the following changes:
# ping wotan
PING wotan.asgard (10.0.2.2) 56(84) bytes of data.
C's getnameinfo() returns: wotan.asgard
Though no change in the behaviour of su, still a 25 seconds timeout
before it succeeds.
In the output of strace I can see that /something/ happens with
libnss, so DNS lookup. But unfortunately I am unable to tell what it
is. But there seems not to be any timeout related to DNS.
Any use of posting a full strace log? I dont think so.
Hopefully someone else will have a better suggestion.
Thank you anyways. Getting any response is always good, instead of
being ignored completely :)
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514422ec.90...@web.de
su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable
Hello,
this is my first message to this list.
I noticed a little problem on my system after I installed the package
virt-manager and its dependencies on my system. One of the
dependencies is dbus.
The problem is that su takes 25 seconds before it succeeds.
Using strace I think I identified the problem:
connect(4, {sa_family=AF_FILE,
path=/var/run/dbus/system_bus_socket}, 33) = 0
...
poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout) 25.028989
The reasons seems to be my setup of the system.
Debian runs in a VirtualBox environment, headless and w/o X server.
I use ssh to connect to the system. (putty)
I use X forwarding to run X applications on the system.
The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.
I only run the X server if it is required for running a X application.
I can skip the timeout if I do either of these two things:
Solution 1) run X server on 10.0.2.2 (Xming)
Solution 2) unset $DISPLAY
Is there something I can change in any of the configurations of dbus
or su to skip the timeout? Maybe don't use dbus for su at all?
System information:
$ uname -a
Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
$ dbus-daemon --version
D-Bus Message Bus Daemon 1.6.8
Best regards
Sven.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5143a009.3080...@web.de
