ID: 10324 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Reproduceable crash Description: reproducable seg fault during generic script exec with pgsql and mcrypt here's the back trace (again without db symbols) of the crash when it happens after my script has completed execution: Program received signal SIGSEGV, Segmentation fault. 0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111 3111 malloc.c: No such file or directory. (gdb) bt #0 0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111 #1 0xfe20fb0 in __libc_free (mem=0xfebb380) at malloc.c:3023 #2 0xf01121c in ?? () from /etc/apache/libexec/libphp4.so #3 0x0 in ?? () (gdb) Previous Comments: --------------------------------------------------------------------------- [2001-04-14 09:46:01] [EMAIL PROTECTED] I've rebuilt php with --enable-debug on (rm config.cache & cleaned the build dirs), but the db symbols still don't appear in the back trace. I am using the standard build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this isn't working as expected. --------------------------------------------------------------------------- [2001-04-14 07:38:40] [EMAIL PROTECTED] Can you try configuring php with --enable-debug, so that better backtraces can be made? --------------------------------------------------------------------------- [2001-04-14 00:19:26] [EMAIL PROTECTED] Hi, I've managed to uncover a reproducable segmentation fault that occurs during execution of a script containing a loop of pgsql mcrypt calls. As best as I can tell mcrypt doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the segfault (although it does seem to change the time/position) when the crash happens. Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, however, on several occausions I managed to get the script to crash after my code had completed and the send buffer had been flushed (only record of a fault was in the error log), so I'm doubtful that the error is in the db code per se. Running gdb seems to show that memory is courupt before the script is run the first time (after researting apache) as can be seen in the trace below (this first memory error is exposed when executing any other script after an apache restart). Once the script runs for a while (it contains a rather expensive loop of db calls) it fails with the seg fault. I've already rebuilt postgres, libmcrypt and php, to no avail... Any ideas would be most appricated! Thanks Kevin --- build flags: './configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' '--with-pgsql' '--with-mcrypt' ---- gdb session: This GDB was configured as "ppc-yellowdog-linux"... (gdb) run -X Starting program: /etc/apache/bin/httpd -X Cannot access memory at address 0x34623731. (gdb) bt #0 _dl_debug_state () at dl-debug.c:56 #1 0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195 #2 0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
