Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Thu Mar 28, 2024 10:35 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: ManiaDrive / shadow bug
PostPosted: Wed Jul 08, 2009 9:49 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Hi,

A few hours ago, I discovered a bug in ManiaDrive (svn 843) where, after having launched the game a few times (5 to 10), the shadows were not displayed anymore.

I consider this bug as quiet serious, not because of its impact on rendered frames, but because it seems related to some memory leak somewhere !

After a long digging, I realized that the trouble is in shadow.c, where glCopyTexSubImage2D() is supposed to store the color buffer into the shadow texture. When the trouble starts, glCopyTexSubImage2D() fails with GL_OUT_OF_MEMORY error (so copy is not done, and shadow map stays empty)

This bug was confirmed on another computer, with almost the same setup : NVIDIA 9600 GT + win32 (186.18 here)

Then it becomes very wired, because if I create a new dummy texture just before creating the shadow map (1), the trouble goes away ! (if the texture sizes >= 128) Same story, if load a texture ... that does not exists ! Since the texture does not exists, it calls R3S, PHP module and so, so it's probably touching heap and stack here and there, and it seems enough for making glCopyTexSubImage2D() working again :/

To anyone using win32: can you try to launch ManiaDrive with the latest SVN, up to 15 times, and see if shadows became broken ? Please report here the result of your tests, with a few informations about your video card.

It can be a good idea to make sure that this bug does not occurs on other targets (Linux) with NVIDIA hardware. I'm pretty sure it's OK with Linux+ATI.

We must make things clear: if it's a NVIDIA driver bug, it's OK (and we can try to report it), but if it's Raydium fault's ... we're facing a huge memory leak :/

(1) just before raydium_texture_load_internal(), in raydium_shadow_enable(), shadow.c.


Top
 Profile  
 
PostPosted: Wed Jul 08, 2009 10:07 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Confirmed on a NVIDIA 8800 gt 512. Drivers 186.18, vista 64 bits, after 5 launches.


Top
 Profile  
 
PostPosted: Wed Jul 08, 2009 11:14 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Tracked down (thanks SVN !) ... the bug was introduced by commit 709 :

Code:
xfennec
2008-08-26T19:57:14.690682Z (revision 709)
Fix for coredumps with recent PHP snapshots (was crashing on repeated PHP requests because of scrambled cache)


Code:
Index: php.c
===================================================================
--- php.c   (revision 708)
+++ php.c   (revision 709)
@@ -318,6 +318,7 @@
 
  php_request_shutdown(NULL);
  raydium_sapi_module.shutdown(&raydium_sapi_module);
+ php_module_shutdown(TSRMLS_C);
  return 1;
 }


So, here's what I think: somewhere around version 5.1/5.2, PHP have changed its shutdown behaviour, making the call to php_module_shutdown() mandatory.

Back to the day of this commit, the only thing I've seen is : it crashes with newer PHP, and when I add proper shutdown, it works perfectly. I then conclude that it was a long time mistake to not call the shutdown, so I added it, supposing it would have no undesirable effect with prior version of PHP.

The last point was actually an error, older PHP probably can't deal correctly with repetitive php_module_shutdown().

To make sure I'm right here, we must try to update the win32 SDK with a newer release of PHP (5.2.x should be enough). Ouille, can you try ? If you don't have time to do it, can you give me a few tips about how you've worked to release the current SDK with PHP 5.1.2 ? From binaries ? From source ? How can I generate the .a ? ...

st, what version of PHP do you use in your SDKs ?


Top
 Profile  
 
PostPosted: Thu Jul 09, 2009 5:35 pm 
Offline

Joined: Tue Jul 08, 2008 2:37 am
Posts: 181
Xfennec wrote:
st, what version of PHP do you use in your SDKs ?
I'm using the same PHP version with the same build options in both Apple SDKs.
The related Apple threads from st wrote:
PHP 5.2.6 http://php.net/
Build options: --disable-shared --enable-embed=static --with-zlib --enable-ftp --enable-static=zlib --with-curl --disable-simplexml --disable-xmlreader --disable-xmlwriter --enable-soap --without-iconv
I never noticed a shadow bug on any Apple system, where I've started and played ManiaDrive a lot of times, nor on my Windows Vista 32-bit notebook using the newest Raydium SDK available.
System overview wrote:
iMac using NVIDIA GeForce 8800 GS OpenGL Engine, from NVIDIA Corporation (version 2.0 NVIDIA-1.5.44).
Notebook using Intel Cantiga, from Intel (version 2.0.0 - Build 7.15.10.1599).
If you want me to test specific cases or if I can help in any other way to solve this problem, please tell me what to do, how I can help to fix this issue. :)


Top
 Profile  
 
PostPosted: Sat Jul 11, 2009 11:14 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

Win32 and php is a complex mix.

I've try during a really long time to build php from source using gcc. In fact it seem's that it's not possible.

So i used your php build from original raydium sdk. This php version is the same since the begining.

I've try to use precompiled binaries of php without succès for lot's of reason. There is probably a message about this in the forum.

So i'll put this to my september todo list. But for php build you are the only one you manage to do it (there where some strange .bat file in the original win32 sdk).

Have a nice day.
Ouille$


Top
 Profile  
 
PostPosted: Sun Jul 12, 2009 3:34 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Ok, interesting. I'll try to have a look too, trying to remember how I managed to compile PHP in the old SDK. Probably some sort of library conversion from VC++ to MinGW.


Top
 Profile  
 
PostPosted: Tue Jul 14, 2009 8:59 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
With Flex, we tried to "convert" php5ts.dll from official PHP binaries to MinGW. We used the following method, that I now remember (more or less) :

- replaced all needed DLL of Raydium's "bin" directory with the ones of the binary package of php.net
- we've generated a .def file from the DLL, using "pexports php5ts.dll > a.def"
- then, generated .lib file from the DLL, using "dlltool -C -d a.def -l libphp5ts.a"

For all this commands, you need to have a PATH that includes the "bin" directory of MinGW, otherwise pexports/dlltool will work weirdly.

- We had to "convert" PHP sources (the correct word is "butcher") to create an "include" for this new PHP version. Remove some typdef, some includes, ... Most of the work is to remove all the Visual Studio specific things.

And we were then able to compile raydium.dll without any error/warning !
But applications just do load: we've a crash during Raydium initialisation (before any PHP init, it seems).

I was unable to debug using gdb (how does it works with the SDK ? I added "-g" flag to compilation, but gdb still complains about missing debugging symbols), but I've found an interesting clue:

The crash also occurs when I replace only the php5ts.dll from a vanilla SDK with any official php5ts.dll coming from any version superior or equal to php-5.2.1 ! The results should be some missing symbols, not a crash ! Something seems to have changed in this release, and the changelog shows nothing special.

Debugging would help. Here it is my current trace of the crash:

Code:
(gdb) run
Starting program: C:\data\raydium_bordel\raydium_win32_sdk_748\bin/cam.exe
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
warning: Lowest section in C:\WINDOWS\system32\odbcint.dll is .rsrc at 1f841000
Raydium: Raydium 3D Game Engine
Raydium: version 0.800
Raydium: command line args: OK
Raydium: chdir to 'C:\data\raydium_bordel\raydium_win32_sdk_748\bin/': OK
Raydium: using 'C:\Documents and Settings\Xfennec/.raydium' as home dir
Raydium: Requesting 640x480:32 mode
Raydium: Found 640x480 with 32 bpp color and 24 bits zbuffer (stencil is 8)
Raydium: using GeForce 9600 GT/PCI/SSE2, from NVIDIA Corporation (version 3.0.0)

Raydium: Signal Handlers: OK
Raydium: OpenGL extensions: OK
Raydium: Platform "4xfloat" vector size is: 16 byte(s) long
Raydium: OpenGL implementation maximum texture size: 8192x8192
Raydium: OpenGL hardware providing 4 texture unit(s), Raydium deals with 4

Program received signal SIGSEGV, Segmentation fault.
0x7c91100b in ntdll!RtlEnumerateGenericTableLikeADirectory ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb)


PS: The odbcint.dll warning is still here with working php5ts DLLs (just tested with 5.2.0).


Top
 Profile  
 
PostPosted: Tue Jul 14, 2009 9:25 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

Perhaps we can continue in french, some english word troubleshouting me a lot :(

First i think we need to work on exactly the same php version. Perhaps a zip with those file will be usefull.

Can we decide to use one specific version of php 5.2.0 for example ?

I already try to get binaries working with some include using binaries and source distribution mix of php without succes.

For debug: i use code blocks without problem, but BUT but ... it's easier to debug on static build than dll build, i have sometime some problems on dll build with some symbols path, this is due to index.c / index.h and thoses stuff that seems to be 'too complicated" for gdb.

About the error it's really strange, no php function are used after opengl hardware texture unit.

The only thing i see is a strncmp perhaps a symbol but it seem strange as this function is already used before.

Can you give me all files used, i'll try to reproduce this on my computer and try to help to find the answer.

have a nice day.
Ouille.


Top
 Profile  
 
PostPosted: Tue Jul 14, 2009 9:39 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
PHP 5.2.0 will work OK. The crashes starts with 5.2.1. To create a test case, it's quiet simple:
- go to http://www.php.net/releases/
- download any zip package (thread safe version [php5ts.dll])
- replace php5ts.dll of Raydium's bin/ directory with the one you'll find in the zip package

That's it, you're now the happy owner of a everything-is-crashing-everywhere version of the SDK :)

Le français, c'est OK pour moi pour ce sujet si tu préfères.
Peut-être devrais-je aussi renommer ce sujet pour un truc comme "mise à jour de PHP pour le SDK win32".


Top
 Profile  
 
PostPosted: Wed Jul 15, 2009 4:57 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

J'ai maintenant une installe qui plante le sdk :)

L'erreur viens (a priori selon moi bien sur) ... du vsnprintf de raydium_log uniquement en cas d'un argument de type %f.

Le test est assez rapide à faire:
Code:
raydium_init_args(argc,argv);
raydium_log("Ok");
raydium_log("Okd %d ",14);
raydium_log("Okf %f",0.234f);


la dernière ligne plante et pas les autres (en commentant les raydium_log %f de raydium ca marche aussi).

Une trace assembleur montre que le raydium_log appelle la fonction de php5ts
Code:
00423C7C  /$ 55             PUSH EBP
00423C7D  |. 89E5           MOV EBP,ESP
00423C7F  |. 81EC 28010000  SUB ESP,128
00423C85  |. 8D45 0C        LEA EAX,DWORD PTR SS:[EBP+C]
00423C88  |. 8985 F4FEFFFF  MOV DWORD PTR SS:[EBP-10C],EAX
00423C8E  |. 8B85 F4FEFFFF  MOV EAX,DWORD PTR SS:[EBP-10C]
00423C94  |. 894424 0C      MOV DWORD PTR SS:[ESP+C],EAX
00423C98  |. 8B45 08        MOV EAX,DWORD PTR SS:[EBP+8]
00423C9B  |. 894424 08      MOV DWORD PTR SS:[ESP+8],EAX
00423C9F  |. C74424 04 FE00>MOV DWORD PTR SS:[ESP+4],0FE
00423CA7  |. 8D85 F8FEFFFF  LEA EAX,DWORD PTR SS:[EBP-108]
00423CAD  |. 890424         MOV DWORD PTR SS:[ESP],EAX
00423CB0  |. A1 A40CEE00    MOV EAX,DWORD PTR DS:[<&php5ts.ap_php_vs>
00423CB5  |. FFD0           CALL EAX                                 ;  <&php5ts.ap_php_vsnprintf>


La question est pourquoi utilise t'on le vsnprintf de la lib php ? et comment pourrai t'on faire autrement.

Enfin a mon humble avis modifier la dll sans changer les headers me semble assez barbare, peut etre faudrait'il reconstruire la dll de raydium avec les header php correspondants et la libphp5ts.a adequate. J'avoue ne pas trop maitriser cette partie du process.

j'ai fait mes tests avec la 5.2.9.

Je continue à chercher ....

Bonne journée
Ouille.


Top
 Profile  
 
PostPosted: Wed Jul 15, 2009 8:00 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Ok, vsnprintf ... c'est déjà une excellente information.

Tu as parfaitement raison de relever que l'utilisation d'une version différente de la DLL et de la lib est une bêtise, mais le problème se posait également avec un ensemble DLL/lib cohérent (dont je décris la construction dans un précédent message). C'est seulement après que je me suis aperçu que le problème se posait directement sans même toucher au .a de PHP. Il semble que quelque chose se soit passé dans PHP à partir de la 5.2.1 concernant ces fonctions de manipulation de chaines. Je vais jeter un œil au changelog.

Le nouveau point de départ est peut être de repartir à zéro pour la construction de la lib (dll -> def -> a) pour se concentrer sur la construction des entêtes (à partir du code source de PHP), ou il est possible que quelque chose soit fait pour "détourner" les appels à vsnprintf vers PHP, à grand coup de #define par exemple. Le pire est que tout ça me dit vaguement quelque chose ...


Top
 Profile  
 
PostPosted: Wed Jul 15, 2009 8:45 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

J'ai corrigé le .a avec ta procedure, le resultat est le meme plantage dans vsnprintf.

J'ai tenté de modifier l'ordre du link pour utiliser le vsnprintf de libmingwex.a sans succès je ne sais pas pourquoi c'est toujours celui de php qui est utilisé. Sur l'ordre du link j'ai peut etre loupé quelque chose.

Je continue les tests quand meme.

Pour les headers j'avais tenté de le faire, je me souviens avoir abandonné a mon avis je devais tourner en rond au bout d'un certains temps.

Bonne journée
Ouille.


Top
 Profile  
 
PostPosted: Fri Jul 17, 2009 10:07 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
OK, donc en suivant la logique, je suis tombé sur le fichier snprintf.h dans le répertoire main des includes de PHP, qui contient les lignes honteuses suivantes :

Code:
#ifdef slprintf
#undef slprintf
#endif
#define slprintf ap_php_slprintf

#ifdef vslprintf
#undef vslprintf
#endif
#define vslprintf ap_php_vslprintf

#ifdef snprintf
#undef snprintf
#endif
#define snprintf ap_php_snprintf

#ifdef vsnprintf
#undef vsnprintf
#endif
#define vsnprintf ap_php_vsnprintf

#ifdef sprintf
#undef sprintf
#endif
#define sprintf php_sprintf


C'est du vol ! :) En commentant tout ce bloc, victoire, le plantage disparait. Je n'ai pas le temps de voir si le reste est OK, il faudrait que je reparte de zéro pour reconstruire le def, la lib et les includes bien propres.

edit : Je viens de faire un test très rapide avec la 5.2.1, et tout semble OK (tests R3S et ManiaDrive, essentiellement). Reste plus qu'à faire un truc au propre :)


Top
 Profile  
 
PostPosted: Mon Jul 20, 2009 9:14 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

Même conclusion, même solution (presque).

J'ai refait le win32 sdk, avec php 5.2.9.

Mise a jour de plusieurs header, pour le pb de vsnprintf et pas mal de redéfinition parfois étranges.

Recrée libphp5ts.a avec pexport et dlltools suivant tes recommandations.

include php ne sont plus postfixé par la version (simplifiera les évolutions).

Full compile tests et tous les samples semblent fonctionner normalement maintenant.

Après 10 lancement successifs de mania drive pas de problèmes avec les ombres.

Maintenant il faut que je retrouve comment mettre la page download a jour avec le nouveau sdk.

Bonne journée
Ouille.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 26 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group