I have an import-from-excel script as part of a CMS that previously ran without issue.
My shared-hosting provider has recently upgraded their infrastructure, including PHP from 5.1 to 5.2.6, and the script now returns "Uninitialized string offset: -XXX in /path/scriptname.php on line 27" (XXX being a decreasing number from 512 and /path/scriptname.php of course being the full path to script in question).
It returns this error for every line of the excel file. Line 27 is just a return from within a function that is the first point at which the imported data is being processed:
function GetInt4d($data, $pos) {
return ord($data[$pos]) | (ord($data[$pos+1]) << 8) | (ord($data[$pos+2]) << 16) | (ord($data[$pos+3]) << 24);
}
It finally implodes with a "Fatal error: Allowed memory size of 47185920 bytes exhausted (tried to allocate 71 bytes) in /path/scriptname.php on line 133".
There's nothing useful in Apache error logs. I am stumped. Anyone have any ideas of at least where to look? Even knowing if it's likely to be something within my script or something to do with upgrade would be useful. I had another issue with a different site on same provider that (after upgrade) couldn't write sessions to tmp directory (since resolved), but am pretty sure it's not that (?).
EDIT: As it turned out that the answer was to do with the version of the parser being incompatible in some way with PHP 5.2.6, I thought it might be of use to someone that the parser in question is Spreadsheet Excel Reader .
Solved here:
http://www.phpbuilder.com/board/archive/index.php/t-10328608.html
Uninitialized string offset:
... means that $data is not an array.
Thanks for the input, the situation has 'resolved itself' via me finding a more recent version of the parsing library I was using. My guess is the issue was something to do with the difference between php versions, though I'm unsure exactly what. Fixed but frustrating.
EDIT: I'm going to accept Till's answer purely in the interests of closing the question. Thx again for input.
Related
Recently I met a weird error and hope someone can help.
We use LiteSpeed WebServer and Nginx on top, with PHP 7.5 and MySQL 5 (well, WordPress is the framework). It runs well for many days.
Suddenly it goes fatal at this line in different files
include ("class-xxx.php");
The error log says
[02-Oct-2018 13:04:36 UTC] PHP Fatal error: require(): Failed opening required 'dlass-xxx.php' (include_path='.:/opt/cpanel/ea-php72/root/usr/share/pear') in /xxx.php on line N
I double checked the code and see that the file name is declared "class-xxx.php", but somehow the server tries to include "dlass-xxx.php", thus it cannot find the file and trigger fatal error.
Solution? I re-upload the file, it works. But then it goes fatal in another file, at similar lines using include.
I notice that the first character in the file name, for example "c", is read incorrectly and shift 1 byte before (or after), so the file name is correct.
Such as
include "class-xxx.php" is parsed/read as "dclass-xxx.php"
include "page-xxx.php" is parsed"read as "opage-xxx.php"
...
this is very strange. Do anybody know the reason? Is it related to any caching/memory management of LiteSpeed or Nginx or PHP 7. ?
It happens on PHP 7. only because if I switch to PHP 5.6, the error does not happen.
Hope someone can help. Thanks a lot.
The problem is very very weird. Let me explain a little bit better - We have a multi site built for the client. Until recently we could edit the homepage with no issues. In the meantime we have upgraded the core (it was still working with new core). Just recently whenever I try to edit the homepage I get this error
Fatal error: Out of memory (allocated 42467328) (tried to allocate 64 bytes) in /home/officete/public_html/wp-includes/wp-db.php on line 1557
Ok so the apparent solution was to change the php memory allowance... Well I have increased it on the server via WHM, increased it in htaccess, wp-config and php.ini file to over 1.2GB (never really expected I will have to increase it so much) just for testing reasons. Every time I try to edit the page I get the same god damn error and 42467328 allocation limit doesn't change at all the " 64 bytes" part does though and its between 32-128 bytes so far.
I am stumped. And have no idea what else I can do. I did contact the server provider they say it looks ok from their end.
I am assuming its the amount of data that is being collected it does contain few ACF repeater fields (15 of them... I know... But I haven't built it). I did disable all the plugins the error persists (I know that disabling them don't really change what is being pulled from db).
BTW The line 1557 is the return result function that returns the query in an array.
you page need more execution time.add below code into config file and try:
define('WP_MEMORY_LIMIT', '128M');
I'm seeing this error in my production server, sometimes (I mean, it seems random, as my site as a decent traffic and so far it just happened 5 times):
[21-Feb-2012 23:43:19 UTC] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 261900 bytes) in /home/xxxxx/xxxxx/xxx.php on line 1811
The funny part is, the file has only 798 lines, and this never happened before to me.
It may have to do with recent changes I made to my scripts, yes, but this error simply doesn't make sense to me.
Please keep in mind that I know what "Allowed memory size exhausted" error means, and I know how to increase the memory limit.
However, my question here is, why is PHP referring to a line that doesn't exist?
I don't know how to fix this problem, because this makes no sense to me.
Thank you.
I've just found what was causing this memory leak.
It was a recent change that was entering in recursion cycle between two functions, although it was a rare event.
The line 1811 is real, yes, but the file that the error was referring is not correct. The line 1811 was from another file (included on that referred one) where one of the functions is.
I still appreciate the help from the people who commented above.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /Library/WebServer/Documents/XMLDataStore.class.php on line 981
The curious thing about this error is not the memory leak, which would be easy enough to troubleshoot. Rather, it is the fact that XMLDataStore.class.php is only 850 lines long, which I have verified in multiple text editors.
This is with the PHP 5.3 bundled with Snow Leopard. I'm not using an opcode cache. Here is my php.ini:
allow_url_fopen = Off
error_reporting = -1
display_errors = 1
display_startup_errors = 1
date.timezone = 'America/Los_Angeles'
output_buffering = Off
realpath_cache_size = 0k
XMLDataStore.class.php has recently been refactored and it used to be longer than 981 lines. It's almost as if PHP has cached a 2-week-old version and is reading that. I'm positive that the current version at /Library/WebServer/Documents/XMLDataStore.class.php is only 850 lines long, though.
Could this be a line break issue? i.e. the PHP interpreter breaking lines differently than your IDE / editor? I don't know about how PHP handles Linux/Mac/Windows linebreaks, but it might be a possibility.
Can you create a fatal error somewhere in the script, and look which line number it shows you?
Could there be some over-long lines in your code (> 65535 characters) that mix up the line counting?
Also what happens if you rename the file, and include it under a new name? THis should take care of any screwed up cache issues.
PHP Seems to have issues with macintosh style line ending, It doesnt count the cr at the end of comments. I had this issue after opening a file on a friends apple.
I used kate on linux and Crimson Editor on Windows to change the end of line back to Unix style and the line numbers worked fine.
If you are getting an error on a non-existant line then it may very well be that PHP is caching it.
Maybe try renaming it then executing it.
Not to sure about Snow Leopard, but I am using it right now and have to say there are a great deal of strange bugs with the OS alone, could be that.
I experienced this error before when I was accessing a DB and storing info in an array, turns out I forgot how large the DB was and when it passed MB on the stack I got that error and it stopped.
If the situation is similar use a more processor heavy approach, such as connect, get a line/ block/ whatever, to something, then go back.
Don't go through everything, store it all, then do something.
Check this out:
Drupal.org memory allocation error
Hope this helps, not sure how clear all of this is.
Maybe show parts of your script to get an idea of what might be causing this.
Here is some more info. I tried the same code on a different Mac running the same version of Snow Leopard - one that is rarely used for development and would not have a version of this file cached - same result.
Next I tried copying the same code to a Solaris box running PHP 5.2.8. I still get the memory error - which is fine and expected, of course, since it does exist - but the PHP error message says this instead:
Fatal error: Maximum function nesting level of '100' reached, aborting! in /export/www/htdocs/XMLDataStore.class.php on line 741
This makes perfect sense, as that is the first line of a method that is being called recursively by another method. Exact same code with same line breaks (LF) checked out at the same revision # from the same SVN repository on all 3 machines.
Bug in PHP 5.3.0 for Snow Leopard? :)
While I have no idea what may cause this wrong line counting (I'm using PHP 5.3 on OSX 10.6, too. No Problems here.), you can narrow down the actual error by dividing your script into smaller parts.
that way maybe you'll find the real location of your error.
And a 850 line PHP file could seriously use some refactoring anyway.
I was experiencing this issue as well recently, in my case (PHP 5.3 on Ubuntu/Nginix under php-fpm5) I had a script that was causing a 500 error with no output (due to it being on production). When examining the error log it mentioned line 589 on index.php which only had lines going up to 453. The solution in my case was support for the short tag was disabled on production but enabled for staging...
ie. <? was disabled and <?php was required for opening PHP tags.
The error in the log was obviously not helpful in my case so it took a while for me to troubleshoot it. I am leaving this suggestion here hoping it will save someone some time.
I wanted to create search engine for my webpage, but during indexing on server it crashes with errors :
Warning: opendir(/admin/lucene/) [function.opendir]: failed to open dir: Too many open files in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 159
Warning: readdir(): supplied argument is not a valid Directory resource in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 160
Warning: closedir(): supplied argument is not a valid Directory resource in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 167
Fatal error: Ignoring exception from Zend_Search_Lucene_Proxy::__destruct() while an exception is already active (Uncaught Zend_Search_Lucene_Exception in /admin/includes/Zend/Search/Lucene/Storage/File/Filesystem.php on line 66) in /admin/test.php on line 549
I am using newest version of ZF. Is there code solution for such error - I run script on localhost and it works great.
Thanks for any help.
It seems the problem is in the large number of segments in the index.
Could you check how much files does index folder contain?
There are two ways to solve this problem:
a) Optimize index more often.
b) Use another MaxBufferedDocs/MergeFactor parameters. See Zend_Search_Lucene documentation for details.
If it doesn't help, please register JIRA issue for the problem.
PHP has hit the limit on the number of files it can have open at once it seems might be an option to change in php.ini, could be an OS (quota) limit or you might be able to tell the indexer to slow down and not have so many files open simultaneously.
This is most definitely a Linux/kernel imposed limitation. Use the following command as root on your machine:
cat /proc/sys/fs/file-nr
Return values are defined as:
Total allocated file descriptors
Total free allocated file descriptors
Maximum open file descriptors
I'm also going to take a guess and say you are on a shared hosting machine. If this is the case, I imagine that this sort of issue may come up frequently.
Finally, the following article provides a good amount of information on Linux and open file descriptors even if it is a little dated.
http://www.netadmintools.com/art295.html