Hello,
crashes that are related to closing modules are probably because a change
in the mcrypt library... I just found this in the manual:
The library is closed by calling mcrypt_module_close(), but you should
not call that function if mcrypt_generic_end() is called before.
and:
int mcrypt_generic_end( MCRYPT td);
This function terminates encryption specified by the
encryption descriptor (td). Actually it clears all buffers, and
closes all the modules used. Returns a negative value
on error. This function is deprecated. Use
mcrypt_generic_deinit() and mcrypt_module_close() instead.
In earlier versions this was neccesairy, but now it can cause crashes. If
I find some more time (hopefully this weekend), I'll dig in it.
regards,
Derick
On Thu, 23 Aug 2001, Michael S. Fischer wrote:
> Would anyone care to comment on this thread? Seems we've uncovered yet
> another mcrypt-related bug in PHP 4.0.6.
>
> Thanks,
>
> --Michael
>
> -----Original Message-----
> From: Dathan Pattishall
> Sent: Thursday, August 23, 2001 10:44 AM
> To: RO - Sever Filoti; Dathan Pattishall
> Cc: Drew Folta; ACP-Split
> Subject: RE: I think I found a mcrypt work around
>
>
> Actually I should of went into more detail, about the work around. I did the
> same thing but did not make the open call global. I committed the changes to
> the splitdb gate, and have it working on realacp06 and realacp08. Take a
> look at url_encode.inc now, and see if the seg fault is still troubling you.
>
>
> Great digging, and thanks for the follow up!
>
> --
> D
>
> |~-----Original Message-----
> |~From: Sever Filoti [mailto:[EMAIL PROTECTED]]
> |~Sent: Wednesday, August 22, 2001 11:42 PM
> |~To: Dathan Pattishall
> |~Cc: Drew Folta; ACP-Split
> |~Subject: Re: I think I found a mcrypt work around
> |~Importance: High
> |~
> |~
> |~Actually I did this kind of digging myself some time ago, but it was
> |~before ticket code push so I didn't get the time to publish
> |~the results.
> |~
> |~Anyway, only commenting mcrypt_generic_end did not do the
> |~trick for me,
> |~apache still segfaulted... strange.
> |~Then I've put the initialization part at global level:
> |~
> |~$__encode_td = mcrypt_module_open (MCRYPT_DES, "",
> |~MCRYPT_MODE_ECB, "");
> |~
> |~$__encode_iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td),
> |~MCRYPT_RAND);
> |~
> |~and reused these variables in called function, as well as removing the
> |~generic_end call.
> |~
> |~Apache stopped segfaulting, and I even ran an ab (apache
> |~benchmark) on a
> |~shop page, thousands of iterations and no segfault :-), also no memory
> |~leaks did occur during the benchmark.
> |~
> |~As about the speed, Dathan is right: module_open/generic_end
> |~translates
> |~in having mcrypt library do dlopen (scan for libs...) on cipher
> |~libraries, allocate buffers, then deallocate buffers and
> |~unload (dlcose)
> |~the modules; this would happen per obfuscated link so it's very
> |~expensive.
> |~
> |~I guess what happens is that after the two mcrypt modules (tripledes,
> |~ecb) are loaded, another .so it's needed and hence loaded; but after
> |~encryption ends and generic_end tries to unload explicitly
> |~(dlclose) the
> |~mcrypt module, dynamic loader whines "cannot close resident
> |~module", and
> |~probably next encryption step works with same module loaded but with
> |~encryption buffers drained and this leads to signal 11.
> |~
> |~Next 'mistery': apache stopped segfaulting but with the hacked code
> |~tested with ab I could see in apache's error log messages like:
> |~
> |~[Thu Aug 16 01:27:09 2001] [notice] child pid 729 exit signal Aborted
> |~(6)
> |~apache: dl-close.c:119: _dl_close: Assertion `new_opencount[0] == 0'
> |~failed.
> |~[Thu Aug 16 01:27:20 2001] [notice] child pid 724 exit signal Aborted
> |~(6)
> |~
> |~A failed assertion, probably related to shared libraries loading /
> |~unloading as well. Fortunately, seems to happen only when an apache
> |~process exists, thus has no user visible effects (response already
> |~sent).
> |~
> |~Dathan Pattishall wrote:
> |~
> |~> Could be, I'll do a more in-depth analysis when I finish
> |~the aw_setup
> |~> script. But when these boxes have 2GB of memory and the apache is
> |~> restarted every day, I don't see this as being much of an issue
> |~> (short-term)
> |~>
> |~> -----Original Message-----
> |~> From: Drew Folta
> |~> Sent: Wednesday, August 22, 2001 3:46 PM
> |~> To: Dathan Pattishall; ACP-Split
> |~> Subject: RE: I think I found a mcrypt work around
> |~> Importance: High
> |~>
> |~> OK, but are the apaches leaking memory (more than usual)
> |~> ?Drew
> |~>
> |~> -----Original Message-----
> |~> From: Dathan Pattishall
> |~> Sent: Wednesday, August 22, 2001 3:27 PM
> |~> To: ACP-Split
> |~> Subject: I think I found a mcrypt work around
> |~>
> |~> After doing some debugging and looking at
> |~> TripleDes, I ran across a resource re-allocate
> |~> function for mcrypt, called mcrypt_generic_end .
> |~> To me this sounds like some sort of destructor
> |~> that is going out of bounds and attempts to modify
> |~> memory that the resource does not own, i.e.. the
> |~> cause of the seg-fault.So, I turned that option
> |~> off, and just allow Zend / Apache control it's own
> |~> resources, and low-en-behold the seg fault stops,
> |~> page rendering is 3 times faster, and I'm much
> |~> happier.if (PHP_VERSION > 3) {
> |~> $td = mcrypt_module_open (MCRYPT_DES, "",
> |~> MCRYPT_MODE_ECB, "");
> |~> $iv = mcrypt_create_iv
> |~> (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);
> |~> mcrypt_generic_init ($td, $__key, $iv);
> |~> $query_string = mdecrypt_generic ($td, $s);
> |~> //mcrypt_generic_end ($td);
> |~> } else {
> |~> $query_string = mcrypt_ecb(MCRYPT_TripleDES,
> |~> $__key, $s, MCRYPT_DECRYPT);
> |~> }I commented out mcrypt_generic_endwhich
> |~> doesThis function terminates encryption specified
> |~> by the encryption descriptor (td). Actually it
> |~> clears all buffers, and closes all the modules
> |~> used. Returns FALSE on error, or TRUE on success.
> |~>
> |~
>
> --
> 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]
>
Derick Rethans
---------------------------------------------------------------------
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
SRM: Site Resource Manager - www.vl-srm.net
---------------------------------------------------------------------
--
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]
