16

I found in my error log this (Note: i didn't removed the filename)

Of course I don't have any script with 1 bn lines.

PHP Version 5.3.3-7
Apache 2

The other weird thing is that I have a 

set_error_handler( 'myHandler' );

To write in the error log other inforamtion too, but with this error it seems PHP just ignores my error_handler. I don't have any code that can generate this errore before my call to set_error_handler

Edit

  • Debian at 64Bit
  • I didn't edit, in the error log there aren't any filename, in fact I don't know which script causes this.
  • I have APC installed
Glorfindel
  • 21,988
  • 13
  • 81
  • 109
dynamic
  • 46,985
  • 55
  • 154
  • 231
  • looks like a bug in PHP for the line number. If this isn't a production server, I'd attempt to downgrade PHP and see what line number you get. Then you'd be able to report it. – pocketfullofcheese Nov 13 '11 at 09:40
  • 3
    This question is best asked in the general user's PHP mailing list, and I suspect that you might have to raise a bug request. In all likelihood the line counter has had an arithmetic overflow of some sort. – bdutta74 Nov 13 '11 at 09:42
  • 1
    Can you provide the script that produces this in its entirety? Do you have looped requires? – Adrian Cornish Nov 13 '11 at 09:55
  • Did you edit the error log and removed the filename or was there no filename? Are you using a 32bit or 64bit system? – hakre Nov 13 '11 at 09:57
  • Looks like the output of an `eval()` command? Check your access logs for anything weird out of the ordinary (look for every log url queries). You may be in the process of being hacked. – Yzmir Ramirez Nov 13 '11 at 10:01
  • I have edited my question. 1. 64bit debian, 2 There aren't any filename there, 3 I don't know which is the script that cause this (I don't even use that much OOP in this website) – dynamic Nov 13 '11 at 10:02
  • 6
    1768776801 is 0x696d6461 in hex, and the the four bytes of this number in little-endian order are the ASCII codes for `a`, `d`, `m` and `i`. I'll second @YzmirRamirez's suggestion that something funny is going on. – Luke Woodward Nov 13 '11 at 10:12
  • Well, you should first start debugging and locate the actual code. Otherwise your question is not saying much w/o the code in question. – hakre Nov 13 '11 at 10:50
  • @Yzmir Ramirez: Warnings in eval()'d code give a file (and the message that it's eval'ed code). – hakre Nov 13 '11 at 11:00
  • Check the Apache Access Log, and try to find files accessed at the same time as these error messages occur. – Jakob Egger Nov 13 '11 at 11:33
  • @JakobEgger: Unfortunatly I disabled access log, they caused too much overhead (GBs written in a single day) – dynamic Nov 13 '11 at 11:34
  • I updated the question with another little pretty thing :) – dynamic Nov 13 '11 at 11:40
  • Please provide the unicode codepoint of `EOT`. Is this `0x04` / `EOT` of US-ASCII? – hakre Nov 13 '11 at 11:47
  • @hakre: notepad++ in the status bar shows (UNIX - ANSI) – dynamic Nov 13 '11 at 13:11
  • Sounds like binary code. Expect everything. – hakre Nov 13 '11 at 13:31
  • Ummm... are you sure if it is *your* PHP script that causes the problem? I'm saying this because you're saying that PHP is ignoring *yourHandler*. Are there files on your server that do not belong there? – Salman A Nov 13 '11 at 14:19
  • @yes: The `find` command looks for files, you can specify diverse times (created, modified etc.) to look for. `$ man find` – hakre Nov 14 '11 at 10:58

1 Answers1

3

This is more a comment than an actual answer:

You need to find out which actual code is triggering the error. As long as you don't it's hard to say what specifically is going on.

To start debugging, ensure that you have configured error logging in your php.ini so it's independent to runtime configuration.

Then you can install xdebug and add backtraces to your log. The important part is here, that it is independent to set_error_handler.

This logging information should already give you more insight. If not, start with remote debugging and step through the code until the warning occurs.

Related Question:

Community
  • 1
  • 1
hakre
  • 193,403
  • 52
  • 435
  • 836
  • Probably your custom error handler is triggering the problem. Could explain why no file is given, but that's guessing only (which should be prevented in debugging). Post your error handler code anyway. But don't rely to your handler in this case, check with xdebug if you can find out more. Should give you results faster. Enable it only if a specific request header is set via .htaccess so you can reproduce on your own but the live site's normal users are not that affected by it. In any case, you introduce your (less tested than xdebug's code) to the live site? – hakre Nov 13 '11 at 11:32
  • Well I would at least suspect it, because normally PHP does not track files and line numbers when invoking it (as it's the error handler), but you should verify this behaviour. What happens if you remove your error handler and just log the errors? Does they still happen? – hakre Nov 13 '11 at 11:45
  • 2
    You can't reproduce, you don't even have access logs. You don't want to debug. Fly blind and fly high. Good luck! (Does not sound that you're worried enough) – hakre Nov 13 '11 at 12:05
  • yes123, why don't you say upfront that you're using APC? It re-orders all code, so it sounds at least plausible APC is related to what happens. – hakre Nov 15 '11 at 09:41