Hi Jan, great you stay on this issue. On Sat, December 28, 2013 15:06, Jan Ehrhardt wrote: > "Anatol Belski" in php.windows (Thu, 26 Dec 2013 23:10:41 +0100): > >> Yeah, there is a page >> https://bugs.php.net/bugs-generating-backtrace-win32.php , the debug >> tool is in current version 2.0 now, but the screenshots are compatible. > > I am now getting this result with a x64 debug build: > > > WARNING - DebugDiag was not able to locate debug symbols for > \php5_debug.dll, so the information below may be incomplete. > > > In > php-cgi__PID__2664__Date__12_28_2013__Time_02_21_08PM__334__Second_Chance_ > Exception_C0000005.dmp > the assembly instruction at php5_debug!gc_init+2687d in > D:\phpdev\php57nts.x64d\php5_debug.dll from The PHP Group has caused an > access violation exception (0xC0000005) when trying to read from memory > location 0x00000000 on thread 0 > > Strange thing: there was a php5_debug.pdb besides the php5_debug.dll. Am > I missing something? The info does not go further than things like: > > > php5_debug!gc_init+2687d php5_debug!gc_init+2684a php5_debug!gc_init+23c67 > php5_debug!gc_init+21488 php5_debug!gc_init+1c658e > php5_debug!gc_init+14868d php5_debug!gc_init+14a008 > > There are a lot more files with info about php5_debug.dll than only the > .pdb: > > > 28/12/13 14:56 16.347.648 php5_debug.dll > 28/12/13 14:48 32.697 php5_debug.dll.def > 28/12/13 14:56 618 php5_debug.dll.manifest > 28/12/13 14:51 1.132 php5_debug.dll.res > 28/12/13 14:56 488.426 php5_debug.exp > 28/12/13 14:56 7.497.392 php5_debug.ilk > 28/12/13 14:56 806.446 php5_debug.lib > 28/12/13 14:56 15.346.688 php5_debug.pdb > > > Which one would be interesting for the debugdiag tool? The *.pdb is the only one relevant. You can check the symbols path in the bins with "dumpbin /pdbpath:verbose ph5.dll" from the VS prompt. Then one can move the *.pdb to one of the paths, or override in DebugDiag like "Tools=>Options=>Symbol search path". The bt looks actually very minimal :) I think it'd make more sense to continue with a release build and --enable-debug-pack or just pull some snap from windows.php.net . Pure debug build contains any possible asserts which are not critical in release builds. Of course the posted BT can show a misbehavior caused by opcache somewhere else, but as it looks strange, the original constellation you had should be more reliable in this case. > >> The issue with gdb is that it can debug only the corresponding builds >> (for >> instance binaries compiled with gcc under mingw). > > Hmmm. GDB knew that it was zend_mm_set_custom_handlers in the DLL. > Yes, the basic structures have of course to match, as that's in any case a windows binary at the out. However compatibility between sections, memory handling, core features - all that and much more makes the interchangeability between gcc and visual studio impossible. Concrete implementations like cygwin or mingw add also their own incompatibilities. If it would work, god, we had already solved the issue with C99 libs ;( Thanks Anatol -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
