Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I tried to debug but heap always crahes on other circumstances. The old windbg reported eg.

Wed Nov 29 17:00:59.046 2006 (GMT+1): HEAP[ntserver.exe]: 
Wed Nov 29 17:00:59.046 2006 (GMT+1): Invalid Address specified to RtlFreeHeap( 930000, 9301b0 )
Wed Nov 29 17:00:59.046 2006 (GMT+1): (300.968): Break instruction exception - code 80000003 (first chance)
eax=009301a8 ebx=009301a8 ecx=031ce2ec edx=031ce086 esi=00930000 edi=009301a8
eip=7789193c esp=031ce26c ebp=031ce270 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202
ntdll!RtlpProcessWaitCompletion+0x11a:
7789193c cc int 3
 
031ce270 778b1cff 009301a8 00930000 009301b0 ntdll!RtlpProcessWaitCompletion+0x11a
031ce284 778b0e88 00930000 009301a8 778b0d6c ntdll!RtlTraceDatabaseEnumerate+0x1e
031ce3bc 778b0fd5 02190000 0219f448 0219f448 ntdll!RtlVerifyVersionInfo+0xab
031ce518 016ad786 00000000 1101bd23 00000001 ntdll!RtlVerifyVersionInfo+0x28b
WARNING: Stack unwind information not available. Following frames may be wrong.
031ce538 015bdbef 11027e88 10bf88e0 11025ed8 php5ts!php_mail+0x926
031ce568 0151a541 05db6108 11020ed0 00000000 php5ts!compare_function+0x4df
031ce57c 015c20f7 11020ed0 1101feb0 01584514 php5ts!efree+0x21
00000000 00000000 00000000 00000000 00000000 php5ts!zval_dtor_func+0x27

Btw. The stacktrace does not help in this case because it always happens on other adresses so the heap corruption is the error not the error itself.

Not reproducible on Linux.
Also, I don't undrestand - why did you report it BOTH to MySQL people and here?
Are you able to replicate it on another machine? Another OS? 
Linux and valgrind would most likely give some more information, not just a random backtrace.

It's reproduceable on windows (ISAPI) - that's all. 

If you run it as CGI it may never happen ?! I have no linux at all here to test neither than other OS'es. I reported to mysql because may the result given back to php is wrong. Sorry for crossposting.

If you're sure that it's not bug but a feature then close this please
but i'm pretty sure that other people on the WWW have similar crashes and if UNIQUE index is corrupting the heap under these circumstances may i can help with this simple tip to check.

I just don't understand what does it have to do with PHP at all - PHP doesn't care if your index is UNIQUE or whether you have an index at all. PHP just passes the query to libmysql.
Therefore I suspect either the problem is actually caused by something else or it has nothing to with PHP at all.

OK i understand. 

I wish i could give you more information but it's just this simple configuration and this simple script. As long as i had the UNIQUE index on the INT(15) field the php crashed with access violation within few hours may dependig on load of webpage.

I tried to debug by using GFLAGS ON but i can see that the heap crahes always on other adresses (but the debugger has never breaked on buffer overflow).

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

I emailed the latest drwtsn log file to your adress, may this helps:

*----> Raw Stack Dump <----*
2e93f3a4  68 4f db 02 5a a8 4b 00 - 00 cf 0f 28 68 4f db 02  hO..Z.K....(hO..
2e93f3b4  a4 c5 66 00 36 80 db 02 - a7 f5 7f 00 00 cf 0f 28  ..f.6..........(
2e93f3c4  88 c8 51 00 68 4f db 02 - 01 00 00 00 0c 05 00 00  ..Q.hO..........
2e93f3d4  78 f4 93 2e b8 1b dc 02 - 68 4f db 02 20 b5 e4 02  x.......hO.. ...
2e93f3e4  f8 f3 93 2e 02 00 00 00 - 80 00 00 00 00 00 00 00  ................
2e93f3f4  f8 88 75 00 2d 31 00 00 - 05 00 00 00 70 ce 0f 28  ..u.-1......p..(
2e93f404  00 00 00 00 06 00 00 00 - f8 a4 4c 00 20 b5 e4 02  ..........L. ...
2e93f414  02 00 00 00 f8 c0 0f 28 - 00 00 00 00 00 00 00 00  .......(........
2e93f424  00 00 00 00 20 b5 e4 02 - f8 c0 0f 28 84 f9 93 2e  .... ......(....
2e93f434  02 00 00 00 24 c2 0f 28 - c8 c2 0f 28 b8 c6 e4 02  ....$..(...(....
2e93f444  57 a5 4c 00 20 b5 e4 02 - 02 00 00 00 f8 c0 0f 28  W.L. ..........(
2e93f454  ef 0e 46 00 10 31 85 00 - cb e4 4c 00 20 b5 e4 02  ..F..1....L. ...
2e93f464  f8 c0 0f 28 f8 ba e4 02 - 1f 10 46 00 10 31 85 00  ...(......F..1..
2e93f474  f8 c0 0f 28 49 6e 63 6f - 72 72 65 63 74 20 74 69  ...(Incorrect ti
2e93f484  6d 65 20 76 61 6c 75 65 - 3a 20 27 2d 31 27 20 66  me value: '-1' f
2e93f494  6f 72 20 63 6f 6c 75 6d - 6e 20 27 71 75 65 72 79  or column 'query
2e93f4a4  5f 74 69 6d 65 27 20 61 - 74 20 72 6f 77 20 30 00  _time' at row 0.
2e93f4b4  0c f9 93 2e 01 f6 93 2e - 0d 00 00 00 01 00 00 00  ................
2e93f4c4  2b 00 00 00 99 e5 57 00 - 16 90 a4 db e4 f6 93 2e  +.....W.........
2e93f4d4  0d 00 00 00 dc f4 93 2e - 01 00 00 00 da 6b 4b 00  .............kK.

So may the error message is written back in wrong memory buffer.

Unfortunately, it's not really useful.
Did you test the snapshot?

Did you checked the drwtsn.log file already ? 
I have no problems with php 5.2.1 and the code since removing the UNIQUE index and setting regular index on this field.

> Did you checked the drwtsn.log file already ? 
Yes, I saw it.
I believe these drwatson logs are not supposed to be human readable, therefore they are just useless.
Please test the snapshot.

With PHP latest DEV and UNIQUE on INT(15) it will happen too; without UNIQUE not.

We're still unable to replicate it.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".