php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #10324 reproducable seg fault during generic script exec with pgsql and mcrypt
Submitted: 2001-04-14 00:19 UTC Modified: 2001-12-13 15:41 UTC
From: kpw at jump9 dot com Assigned:
Status: Closed Package: mcrypt related
PHP Version: 4.0.6 OS: Linux PPC (yellow dog 1.2) and R
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2001-04-14 00:19 UTC] kpw at jump9 dot com 
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\002?\222a", mode=1948280425, 
    caller=0x7fffbdf8) at dl-open.c:232
#3  0xfede368 in dlopen_doit (a=0x7fffc018) at dlopen.c:41
#4  0x3000c078 in _dl_catch_error (errstring=0xfeef630, operate=0xfede314 <dlopen_doit>, 
    args=0x7fffc018) at dl-error.c:141
#5  0xfedeb04 in _dlerror_run (operate=0xfede314 <dlopen_doit>, args=0x7fffc018)
    at dlerror.c:125
#6  0xfede3c4 in __dlopen_check (file=0x30026c70 "", mode=250742837) at dlopen.c:53
#7  0xf0053a0 in ?? () from /usr/lib/libltdl.so.0
#8  0x0 in ?? ()
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xf0e2c5c in ?? () from /etc/apache/libexec/libphp4.so
(gdb) bt
#0  0xf0e2c5c in ?? () from /etc/apache/libexec/libphp4.so
#1  0x0 in ?? ()
(gdb) Quit

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-04-14 07:38 UTC] derick@php.net 
Can you  try configuring php with --enable-debug, so that better backtraces can be made?
 [2001-04-14 09:46 UTC] kpw at jump9 dot com 
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 09:54 UTC] kpw at jump9 dot com 
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)
 [2001-05-27 19:27 UTC] sniper@php.net 
Should be fixed in CVS now. Fix will be in PHP 4.0.6.
If this happens with it too, reopen this bug report.

--Jani
 [2001-07-03 10:48 UTC] kpw at jump9 dot com 
Hi,

This still seems to be a problem in 4.0.6.  I'm pretty sure that it is caused by specific strings being passed into mycrypt, however, I'm not sure what string characteristics cause the problem.  

kpw
 [2001-07-03 11:28 UTC] kpw at jump9 dot com 
Here's an example:

If encrypt the string "Reed, Phyllis" with the key "70094cc48e1a23bf6fec60c2db6e4b71" using blowfish in CBC mode mycrypt will seg fault.  However, if I change the string to "Reed,Phyllis" (no space) everything's fine.  Removing a chacter from the end (""Reed, Phylli") doesn't fix the problem though, so it's apparently not length related.

Very strange indeed...
kpw
 [2001-07-03 22:51 UTC] kpw at jump9 dot com 
Here's the link to a script that exhibits this problem 100% of the time on my PPC/YellowDog server as well as a production machine at phpwebhosting.com:

http://www.jump9.com/_testcrypt.txt 


I've tried this under several version of php (including the current 4.0.6) as well as with every available release of libmcrypt (2.4.7-2.4.15) all without effect.  Given that I have the same problem on a production webserver at phpwebhosting as I do on my own homemade PPC linux box I'm guessing this is real problem...

Any thoughts would be greatly appreciated...


kpw
 [2001-07-04 04:15 UTC] derick@php.net 
Assigning to myself
 [2001-07-04 13:16 UTC] kpw at jump9 dot com 
Sorry,

I was wrong about the exact string that causes the problem I mentioned yesterday... I remembered that I'm actually URL encoding the data prior to encrypting it so the string is really "Reed%2C+Phyllis". The key is still "70094cc48e1a23bf6fec60c2db6e4b71"...

Take care,
kpw
 [2001-12-13 15:41 UTC] derick@php.net 
Should be fixed in CVS, can you try (in about a day) the 
latest snapshot from snaps.php.net ?

Derick
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 23 22:01:31 2024 UTC