[C++] Gros bug

[DanSteph]

plus

Dan



Message modifié ( 22-09-2007 14:24 )

[JLuc]

J'arrive aprés la guerre certainement, et avec des connaissance de novices, mais ...

picto a écrit:
[
   PanelDockStatus[merde].dPressure=100.00f;

il me semble que ton dPressure est une valeur double (le d je pense), alors que tu forces une valeur float 100.00f.

Les conversions, c'est pas toujours du gateau.

C'est juste une petite idée. Des fois, je ferais mieux de la fermer.

JLuc

[picto]

Merci JLuc, mais le gros problème que j'avais était cette erreur de signe qui
m'empêchait de remplir les tableaux. Donc jouer ensuite avec une trentaine
de variables mais qui sont toutes à zéro ... ben :sacl:

[picto]

C'est étrange ces problèmes de focus sur Orbiter quand même .
J'ai un CTD quand je dédocke le DGIV mais en VUE INTERNE DU DGIV.
En cliquant sur le bouton du panel du haut par exemple.

C'est sur cette ligne

         OBJHANDLE DockObjHandle=GetDockStatus(Dock);
         if(DockObjHandle)
         {
         PanelDockStatus.DockingStatus=TRUE;
         PanelDockStatus.dPressure=100;
         }
         else
         {
         PanelDockStatus.DockingStatus=FALSE;
         PanelDockStatus.dPressure=0;
         SetEtatBascule(CREW_MANAGEMENT_CLOSE_OUTER_DOOR,CLOSED);
         }

Or ce SetEtatBascule fait aussitôt appel à un Trigger que j'ai pourtant protégé par un
   if(oapiGetFocusObject()!=GetHandle())
      return;

Donc toujours la même chose ...
Orbiter essaye de dessiner sur un objet dont il n'a pas le focus ...
C'est dommage parce que ça me permettrait de ne pas perdre trop
d'air dans Irridium si un zozo s'amuse à dédocker un truc sans prévenir

Je ferais peut être mieux de stocker la variable puis de l'utiliser au moment du focus sur Boulinium peut être.
Mais ça avait quelque chose de sympa de déclencher des événements pendant un dédocking ... tout de suite.



Message modifié ( 25-09-2007 09:40 )

[DanSteph]

Avant de partir dans les truc compliqué essaie de voir si c'est réellement la cause.
Tu met un F9 dans la clbkDockBidule quand ca intercepte tu F10 jusqu'au crash...

Le redraw orbiter ne dois PAS etre appelé donc c'est pas la cause du crash
(a moins que t'ai pas mi un "MyRedraw" ?)

Dan



Message modifié ( 25-09-2007 12:38 )

[picto]

J'ai plus de crash sans avoir rien tripoté
Et oui, SetEtat fait bien appel à un MonMienTriggerRedraw



Message modifié ( 25-09-2007 15:25 )

[picto]

C'est reparti pour la FAQ .... Foire aux Questions .... in French.

J'ai un avertissement en debugging sur MSVC.
D'habitude, ce genre d'avertissement se termine par un crash, ce qui est bien pratique
pour trouver l'origine du problème, mais là rien ... ça passe sans CTD donc je suis bien
embêté pour "tracer" le problème car la seule info dont je dispose est celle ci.

Exception de première chance à 0x7c812a5b dans Orbiter.exe:
Exception Microsoft C++ : int à l'emplacement mémoire 0x0da4ef68

La question : Comment savoir de quoi s'occupe la case 0x0da4ef68 ?

J'ai une petite idée là dessus mais si c'est ce que je crois je ne suis pas sorti de l'auberge.
Il faudrait afficher le code ASM sur MSVC et essayer de comprendre ce
qui fait quoi autour de cette case mémoire j'imagine ...

[DanSteph]

Essaie de faire "arretter" puis ensuite regarde le "call stack" et clique si tu vois "irridium" pour voir quel fonction est
appellée.

Ensuite procede par élimination, garde exactement le meme scenario mais "desactive" (return ou commente) le code
soupconné, si ca ne fait plus tu a trouvé.

Si le call stack ne donne rien de probant il va falloir un gros flair et regarder les dernier ajouts que tu a fais.
Essaie de desactiver des codes récents jusqu'à que ca ne fasse plus l'erreur.


Le "call stack" c'est un peu un historique de tout ce qui à été appelé recemment que ce soit dans ton module
orbiter win32 etc etc... En haut tu a le plus récent et au fur et a mesure que tu descent les plus vieux.



Dan

[picto]

Je ne vois pas de ligne Irridium dans la pile.
Par contre, sur la fenêtre de gauche je vois ça.
Et en code machine ça me pointe toujours le même endroit, de la
même façon qu'une ligne en C++ est pointée en cas de CTD.

Ca se passe au moment du lancement d'Orbitter sur le Splash screen.
J'ai donc l'impression que ça se passe au niveau du ClassCap.
J'ai bien une idée, là dessus. J'ai fait des appels à des Trigger dans classCap.

Sans doute pas une très bonne idée.  

Et ça ne crasherait pas parce que c'est protégé par le test de focus.

[DanSteph]

A gauche rien a voir, c'est le dernier contexte que tu a affiché.

Donc va falloir cerner a quel moment ce passe ce warning,
met des points d'arret dans ton code, au début de clbkSetclasCap et regarde
si le warning ce produit avant ou après, si avant pas de la faute d'irridium
, si apres etc etc...

sinon balance again tout le code et je regarde si ca fait chez moi.
(me manque toujour les panels en passant)

Dan

[DanSteph]

picto a écrit:
J'ai fait des appels à des Trigger dans classCap.

Me semble une très mauvaise idée vu que ton panel n'existe pas a ce moment

Dan

[picto]

Vi je sais .... ce sont des restes des conneries d'initialisations dues à
la non compréhension des restore par scenario.
Mais je nettoie ... petit à petit, et j'en profite pour corriger tous les petits bugs
annexes que je trouve.

Je vais regarder de ce côté en premier.

C'est difficile quand même le débuggage je trouve.
Pour les panels, tu veux dire les bitmaps ?

[DanSteph]

picto a écrit:
Pour les panels, tu veux dire les bitmaps ?

Vi...

pour le débuggage ca dépend ce que tu entend exactement par la...
ca couvre un champ immense.

Dan

[picto]

Ben tout ... le réglage des détails.
Ou le traçage de bidules comme ça.

C'est rarement évident au premier coup d'oeil.
Par exemple, je viens d'en régler un que pas un des testeurs n'avait vu ...
(on se demande à quoi ils sont payés d'ailleurs ) et qui se trouve sur
le premier système que j'avais fait .... donc deux mois que j'aurais dû le voir mais non ...

En fait, il était possible d'entrer des valeurs dans le remote thrust avec le display correspondant
éteint. Rien de méchant, mais un peu naze, et des trucs comme ça, tout en cleanant les trucs plus
grossiers, c'est trois ou quatre par jours que j'en corrige.

Là, par exemple, c'est difficile, ce ne sont pas les trigger, ( je les ai quand même mis dans le first step
de post step ... et je n'ai pas l'avertissement sur un autre scenario avec Boulinium. Mais je ne suis
pas plus avancé:si c'est une erreur sur le scenario je devrais avoir un CTD d'Orbiter normalement.

[DanSteph]

picto a écrit:
Par exemple, je viens d'en régler un que pas un des testeurs n'avait vu ...
(on se demande à quoi ils sont payés d'ailleurs ) et qui se trouve sur
le premier système que j'avais fait ....

Ben faut raler auprès du premier d'entre eux qui en plus *ca tombe bien*
connais le mieux le code et l'addon: l'auteur

J'ai testé un peu irridium mais à ce stade c'est encore de la pre-alpha
j'en ai vu pleins des trucs d'affichages et autres. Comme tu est en train
de tout revoir ca vaut pas le coup la.

Mais oublie pas que le premier testeur c'est toi, a chaque fois qu'on a fini *un truc* (série)
on teste *le* truc sous toutes les coutures et dans tout les domaines ou le nouveau code
peut etre impliqué: décollage, docking, undocking, atmo, plusieurs vessels dans les scenario,
avec d'autre vessels, depuis un scenario vide, les save/restore des etats, consistance
avec les autres systèmes, switch focus et back etc etc...

pour ca aussi que bosser en parallele est suicidaire. Trop de trucs en même temps,
impossible à mettre au point.

Beta c'est quand *toi* tu vois plus rien et estime que c'est bon...

A peluche

Dan



Message modifié ( 15-10-2007 03:24 )

[DanSteph]

DanSteph a écrit:
décollage, docking, undocking, atmo, plusieurs vessels dans les scenario,
avec d'autre vessels, depuis un scenario vide, les save/restore des etats, consistance
avec les autres systèmes, switch focus et back etc etc...

En passant pourquoi pas une check-list "standard" pour ne rien oublier ?

-Switch Focus
-Spawn par scenario editor
-chargement depuis scenario vide
-save/restore etat
-consistance avec autres systeme dépendant

etc etc...

Tu fais que ce qui s'applique a ton nouveau truc... mais ca pourrait aider a rien oublier.
(en plus des test spécifique, tu va pas mettre "refuelling" dans le check-list of course)

Dan

[DanSteph]

Sinon quand tu estimera avoir fini le "cleaning" je suis pret à revoir le code des fois
qu'un truc t'aurais echappé (deux paire d'yeux... patati) Je vais pas tout revoir
(c'est trop compliqué, j'y passerais une semaine) mais dans les principes de codage y
a des trucs qui risquent de me sauter au yeux.

Dan

[picto]

Sympa, ta proposition de second regard parce que par moments ....

Mais bon, ça avance ce cleaning ... j'essaye d'être méthodique.
Par exemple, je reprend toutes les indentations des fonctions piquées sur
d'autres cpps de la SDK, et des détails apparaissent lors de ce genre de
lecture plus calme.

Pas bête l'idée de la check list .... je prend.
PS, les bitmaps sont sur FTP ... normalement tu auras tout.
Sauf les dernières versions des cpps cleanés oeuf course.



Message modifié ( 15-10-2007 04:17 )

[DanSteph]

picto a écrit:
PS, les bitmaps sont sur FTP ... normalement tu auras tout.
Sauf les dernières versions des cpps cleanés oeuf course.

Got it..

Dan