View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000028XdebugUncategorizedpublic2003-11-11 12:172004-09-15 09:08
Reportermelvyn Assigned Toderick  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionunable to reproduce 
Summary0000028: xdebug_llist_init (l=0x0, dtor=0x190b7d6c <hash_element_dtor>)
Description

Reproducable crash.
Requesting a 'Data Dictionary' on a database in phpMyAdmin 2.5.4 triggers the bug. I currently have no time to further investigate the actual trigger condition, but demonstrative patch is below

Additional Information

Index: xdebug_llist.c

RCS file: /repository/xdebug/xdebug_llist.c,v
retrieving revision 1.4
diff -u -r1.4 xdebug_llist.c
--- xdebug_llist.c 20 Feb 2003 14:30:54 -0000 1.4
+++ xdebug_llist.c 11 Nov 2003 11:15:22 -0000
@@ -29,6 +29,11 @@
xdebug_llist *l;

    l = malloc(sizeof(xdebug_llist));
  • if ( !l )
  • {
  • / do proper clean up here /
  • exit(8);

  • }
    xdebug_llist_init(l, dtor);

    return l;
TagsNo tags attached.
Operating SystemFreeBSD ghost.lan.webteckies.org 4.9-RC FreeBSD 4.9-RC 0000006: Wed Oct 1 07:44:36 CEST 2003 root@ghost.lan.webteckies.org:/usr/obj/usr/src/sys/GHOST i386
PHP Version4.3.4-dev

Activities

derick

2003-12-01 15:44

administrator   ~0000067

I could not reproduce this with 4.3.5-dev, xdebug-2.0dev (current CVS) and phpmyadm 2.5.4. Can you please tell me which xdebug related php.ini settings you made and whether you have a debug or non-debug php build?

melvyn

2003-12-02 01:28

reporter   ~0000071

Try --enable-memory-limit, default setting (8M) and a large enough number of tables (in my case 41). I've screwed around with my php install in the mean time.

Xdebug version above was used, but 1.2.0 was also affected.
I thought the bug would be clear from the patch, that the success of the malloc was not checked. I found that backtracing.

AFAIR auto_trace and default_enable we're on. No phpdebug build.

melvyn

2003-12-02 21:56

reporter   ~0000072

I'm pretty sure I've found the cause:
28094 www 2 0 320M 305M sbwait 0:09 10.27% 9.91% httpd

28126 www 2 0 22176K 14552K sbwait 0:07 25.31% 23.78% httpd

The first run is with 'autotrace' on. The second one, without. Apache was stopped and started before the first run and in between the runs.

Both requested the data-dictionary of the same database. Since I've now compiled php without memory limit, I do not hit the bug anymore but 300M difference for autotrace seems to be a bit much - especially for a webserver. If there is no bug here, then maybe autotrace should be disabled when sapi != cli.

php -i | grep xdebug

xdebug
xdebug support => enabled
xdebug.auto_profile => Off => Off
xdebug.auto_profile_mode => 0 => 0
xdebug.auto_trace => Off => Off
xdebug.collect_params => Off => Off
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.manual_url => http://www.php.net => http://www.php.net
xdebug.max_nesting_level => 64 => 64
xdebug.output_dir => /tmp => /tmp
xdebug.remote_enable => Off => Off
xdebug.remote_handler => gdb => gdb
xdebug.remote_host => localhost => localhost
xdebug.remote_mode => req => req
xdebug.remote_port => 17869 => 17869

derick

2004-09-15 09:08

administrator   ~0000192

I'm going to mark this bug as resolved, as I'm still unable to duplicate it. If you have more information about it, feel free to reopen it. Besides that, the tracing in Xdebug 2.0 is much better anyway (and doesn't use much memory at all!)

Derick

Issue History

Date Modified Username Field Change
2003-11-11 12:17 melvyn New Issue
2003-12-01 15:44 derick Note Added: 0000067
2003-12-01 15:44 derick Status new => feedback
2003-12-02 01:28 melvyn Note Added: 0000071
2003-12-02 21:56 melvyn Note Added: 0000072
2004-09-15 09:08 derick Status feedback => resolved
2004-09-15 09:08 derick Resolution open => unable to reproduce
2004-09-15 09:08 derick Assigned To => derick
2004-09-15 09:08 derick Note Added: 0000192
2016-07-31 12:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 12:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized