This error happens while encoding the session after request end, so there's no active script anymore. Not sure we can make it more verbose.

uhm at least the full path of the invoked script should be known
hence it would be even better if it only says the folder
but wild guessing on a server with 600 domains?

"so there's no active script anymore"

but someone / something invoked a script in which 
context whatever code runs

This error is raised at R_SHUTDOWN (Request Shutdown) that is all script 
execution is *finished*. Therefore, there is no way to know which script caused 
this.

Current session module uses special serializer that do not accept numeric key. 
e.g. $_SESSION[1] = 'foo'; This limitation is came from register_globals.

I think it's safe that remove this limitation, but I have to look code again. I 
also have plan to use plain serializer for session.

well, i see this first time after we upgraded to PHP 5.4 where no longer register_globals is available while we disabled it 10 years ago which took a lot of time prepare because the braindead change in htmlentities() return empty strings without any warnings if ISO-8859-1 is used and not explicit set as param (thanks again for such lowbrained backward compatibility break without a global setting to fix it)

and yes we have watchdogs mailing twice a hour any php-warning and E_ALL in production since years.................

I have plan to clean up encoding setting mess also.
I can understand your irritation :)

Anyway, if you are managing hundreds of domains, you should participate testing 
new minor version release process. Speak out what is going to be your problem to 
internals ML.

I'll commit new serialize handler "php_serialize" to master as the default in a 
few days.

This solves your problem, but the fix is only in Next PHP.

so you tell me i will get the mails below twice a hour until PHP 5.6 is finished and rolled out on my servers? seriously?

and *yes* we are in production with error_reporting E_ALL + E_STRICT since 10 years for currently 600 domains and yes since we devleop our own cms-systems it is reasonable to get such notifies because they are practically bugfree

-------- Original-Nachricht --------
Betreff: Cron <root@arrakis>      php /scripts/rh_watchdog.php
Datum: Fri,  9 Aug 2013 11:30:01 +0200 (CEST)
Von: Cron Daemon 
An: root

[09-Aug-2013 11:00:35 Europe/Vienna] PHP Notice:  Unknown: Skipping numeric key 1 in Unknown on line 0

I was suggested to releasing new "php_serialize" serialize handler for 5.5 (and 
5.4) that removes this limitation.

However, there are objections to include the new serializer.

See internals@php.net archive for details. It is under discussion now. If you 
would like to see this in released version, you should speak out now. Otherwise, 
I have to commit the patch only to development branch.

> I was suggested to releasing new "php_serialize" serialize handler for 5.5 
(and 
5.4) that removes this limitation.

Sorry for broken English.
This should be something like

I proposed to release new ""php_serialize" serialize handler for 5.5 (and 
5.4) that removes this limitation to internals@php.net.

Related to Bug #51127
Related to Bug #25630

Related to bug #43980

Related to Bug #49622

Related to Bug #42725

> See internals@php.net archive for details. 
> It is under discussion now. If you would 
> like to see this in released version, you 
> should speak out now

i am not allowed to speak out on internals because the can not handle clear words and prefers endless discussions in cas of proposed backward compatibility changes and so i am blocked

however i do not understand the disussion - this is a bug and a regression somewhere because we have since 10 years "error_reporting = E_ALL | E_STRICT" and these messages are coming since the upgrade to PHP 5.4

what we need is *NOT* a new session handler beause numeric indexes are braindead and so what we need is a clean error message and *NOBODY* can tell me that it is not possible to have request-uri and/or path of the script which is executed and if this is the case why in the world are tese data thrown away instead held in memory to give useful error messages

*OR* remove this idiotic warning from the code without forcing us to lower the error_reporting

"in Unknown on line 0" is laughable and PHP should simply sht up if it has nothing helful like file and line-numver to say - period

> what we need is *NOT* a new session handler beause numeric indexes are 
braindead and so what we need is a clean error message

If I fixed the issue in current serialize handler, it will break apps. 
Therefore, new one is needed.

The reason you didn't get the error message is it was slightly failed.

I cannot do anything but introduce new serialize handler.

> it is not possible to have request-uri

This one is workable option.

yeah, introduce new things and let the broken untouched broken is the way of PHP which leaded to all the troubles over the last 10 years - hence the real bug is that the info wich script was called is thrown away before the error_handler is raised and burry this problem with a new session_handler does not solve it

*there must not* be any place inside PHP where the error-handler says "in unknown" - it doe snot matter if the script has finished by raise the error, the fact is that the REQUEST has a URL and the error handler comes after the script was executed - so PHP has to store whereever the script path or fix the error_handler that it shut's up if it has nothing helpful to say

Assigning numeric array index valid operation while it was not valid to have 
numeric variable names. That's the reason why old serializer do not allow to save 
such data. Session data is usually saved *after* scripts execution.

My patch should be able to applied to PHP 5.4 cleanly. If you want it to be fixed 
seriously, apply my patch and use php_serialize. Beware that it won't work if you 
mix serializers on shared session data.

yes it is *saved* after script execution

but that is no excuse not store the script path and throw it out in the error message so someone knows which of the some hundret thousands scripts on the server is triggering the error to debug whatever application

so again: we do not need a *incompatible* new session handler, we need proper error-reporting and "in unknown" is always a *major bug* and design flaw

> so again: we do not need a *incompatible* new session handler, we need proper 
error-reporting and "in unknown" is always a *major bug* and design flaw

This is not feasible option. If PHP should detect invalid session data 
assignment, PHP should monitor every writes to variable, not only $_SESSION 
array, during execution only for "register_globals" limited serialize handler. 
There is no such API in PHP. If we made it, it slows down PHP and nobody is 
willing to do. (Technically, Zend engine provides handler for assignment. By 
using the API, anyone can make a module that detects invalid writes to 
$_SESSION)

It seems current documentation does not state that users are not able to save 
numeric index session vars (and other special chars). However, older documents 
explicitly states numeric session vars are prohibited/unsupported. It's our 
document bug, but this is the way it supposed to work.

Therefore, correct way of fixing this "*major bug* and design flaw" is 
introducing new serialize handler that is *not* bonded to register_globals. 

Anyway, I may be able to add REQUEST_URI to the error. Do you want it? It can be 
retrieved via custom error handler, though.  

Another feasible option for you is that define user error handler that ignores 
this error. Since we are not going to add new serialize handler to released 
branch, it would be most feasible option for you. Or write your own module that 
monitor assignments and raise error for invalid.

> This is not feasible option. If PHP should detect invalid 
> session data assignment, PHP should monitor every writes to 
> variable

WTF - nobody needs to monitor anything to know the script
which is called - the design flaw is that this information
well known as long the script is running is *thrown away*
before the last possible event triggering an error and over
years nobody spent a second to fix this

> Anyway, I may be able to add REQUEST_URI to the error. 
> Do you want it? 

that is what i request all the time

> It can be  retrieved via custom error handler, though.

not a option in case of *600* vhosts

> Another feasible option for you is that define user 
> error handler that ignores this error

another option would be fix PHP's internal error handler
that it shuts up in case it has nothing useful to say

We don't have a reliable REQUEST_URI or such available. We only have the version in $_SERVER which might be changed by the user. 

In shutdown we also have no idea of what might have been the "main" script - a SAPI can execute multiple files in a row (as auto_[ap|pre]pend_file do), apache_filter is an example.

A way to improve the error might be saving the place where a session is started, while that costs a tiny bit of memory and CPU.

> We don't have a reliable REQUEST_URI or such available. 
> We only have the version in $_SERVER which might be changed 
> by the user

which is more realiable as "in unknown"

> A way to improve the error might be saving the place 
> where a session is started, while that costs a tiny 
> bit of memory and CPU

the cost is not measureable and does even not exist in theory

php_serialize will be available from PHP 5.5.4.

http://git.php.net/?p=php-
src.git;a=commit;h=c51f77fe83cea3a48d89423863e6916b77628e47