#29419 [Com]: session_destroy() returns "session object destruction failed"
ID: 29419 Comment by: example at example dot com Reported By: roberto_stivanello at libero dot it Status: Open Bug Type: Session related Operating System: Windows NT WEBS119 5.2 build 379 PHP Version: 4.3.7 New Comment: Also under Linux (LAMP). I run a high-traffic website under LAMP and this bug occurs on my system as well. Previous Comments: [2004-07-28 06:56:46] roberto_stivanello at libero dot it Additional information on error reported: PHP Version 4.3.7 System Windows NT WEBS119 5.2 build 3790 Build Date Jun 2 2004 15:45:18 Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp, compress.zlib PHP Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On always_populate_raw_post_data Off Off arg_separator.input & & arg_separator.output & & asp_tags Off Off auto_append_file no value no value auto_prepend_file no value no value browscap no value no value default_charset no value no value default_mimetype text/html text/html define_syslog_variables Off Off disable_classes COM COM disable_functions no value no value display_errors On On display_startup_errors Off Off doc_root no value no value docref_ext no value no value docref_root no value no value enable_dl On On error_append_string no value no value error_log no value no value error_prepend_string no value no value error_reporting 2047 341 expose_php On On extension_dir ./ ./ file_uploads On On gpc_order GPC GPC highlight.bg #FF #FF highlight.comment #FF9900 #FF9900 highlight.default #CC #CC highlight.html #00 #00 highlight.keyword #006600 #006600 highlight.string #CC #CC html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path .;c:\php\includes .;c:\php\includes log_errors Off Off log_errors_max_len 1024 1024 magic_quotes_gpc On On magic_quotes_runtime Off Off magic_quotes_sybase Off Off max_execution_time 120 120 max_input_time -1 -1 open_basedir no value no value output_buffering no value no value output_handler no value no value post_max_size 8M 8M precision 12 12 register_argc_argv On On register_globals On On report_memleaks On On safe_mode Off Off safe_mode_exec_dir no value no value safe_mode_gid Off Off safe_mode_include_dir no value no value sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] sendmail_path no value no value serialize_precision 100 100 short_open_tag On On SMTP localhost localhost smtp_port 25 25 sql.safe_mode Off Off track_errors Off Off unserialize_callback_func no value no value upload_max_filesize 50M 50M upload_tmp_dir C:\PHP\uploadtemp C:\PHP\uploadtemp user_dir no value no value variables_order EGPCS EGPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off y2k_compliance Off Off bcmath BCMath support enabled calendar Calendar support enabled com Directive Local Value Master Value com.allow_dcom Off Off com.autoregister_casesensitive Off Off com.autoregister_typelib Off Off com.autoregister_verbose Off Off com.typelib_file no value no value ctype ctype functions enabled ftp FTP support enabled mysql MySQL Support enabled Active Persistent Links 0 Active Links 1 Client API version 3.23.49 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no value no value mysql.default_password no value no value mysql.default_port no value no value mysql.default_socket no value no value mysql.default_user no value no value mysql.max_links Unlimited Unlimited mysql.max_persistent Unlimited Unlimited mysql.trace_mode Off Off odbc ODBC Support enabled Active Persistent Links 0 Active Links 0 ODBC library Win32 Directive Local Value Master Value odbc.allow_persistent Off Off odbc.check_persistent Off Off odbc.default_db no value no value odbc.default_pw no value no value odbc.default_user no value no value odbc.defaultbinmode return as is return as is odbc.defaultlrl return up to 4096 bytes return up to 4096 bytes odbc.max_links 0 0 odbc.max_persistent 0 0 overload User-Space Object Overloading Support enabled pcre PCRE (Perl Compatible Regular Expressions) Support enabled PCRE Library Version 4.5 01-December-2003 session Session Support enabled Registered save handlers files user Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 On On session.bug_compat_warn On On session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: example at example dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Previous Comments:
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid multibyte sequence
in argument");
}
[2011-03-10 17:37:31] pinkgothic at gmail dot com
I'm afraid this isn't just confusing, but actually punishes people who
do it right by blindsiding them completely.
Scenario:
* display_errors off
* an Exception-throwing error handler
As far as I'm informed, this is good practise. (I acknowledge I may be
misinformed.)
However, due to this behaviour, you suddenly get application crashes in
production without that anyone really
understands why the code snippet is suddenly a culprit. 'But we tested
it with broken UTF-8, why are -we- just
getting empty strings? And the documentation says that's what we should
be expecting...'
> If a configuration variable tells that errors are shown on screen then
I
> think all errors (dependent on reporting level) are shown - and not
that
> they can be only logged if the configuration variable is turned off.
> I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
> For debugging, I would suggest always logging errors and checking the
> error log, as some errors may be hard to spot in display anyway
> (especially true if your script produces something like JSON).
Well, from my experience, people who deliberately turn display_errors on
for development except their feedback in
the browser window [*unless* they are writing for XHR], not in a log
they may also be running in parallel.
This is especially true if you have a complex application that logs
debug information from several services into one
file in a compact format - so, unless you're LOOKING for an error, you
won't spot anything. (Total sidenote, I
honestly wish I could change the log format I have to suffer... but I'm
stuck with it. Gargh.)
If you've been a good developer and read the manual on
htmlspecialchars(), you're not going to expect an error.
You're going to expect an empty string. Unfortunately currently, nothing
in the documentation reveals that the
function results in an E_WARNING, either pure-log-only when
display_errors is on, or log and trigger_error()ed when
display_errors is off.
By the time you find this closed php bug... well, if you're lucky,
you've forced your developers to have a wrapper
function you can now add a try-catch to - otherwise you can now do a
project-wide search for every call of the
function. [To be fair, I was fortunately lucky.]
Could this bug please get REOPENED as a documentation bug? I think
adding this behaviour to the documentation would
help a lot of people confused by it.
[2010-06-14 13:30:05] trueleader at gmx dot de
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed
