Plantage Intel mais pas PPC ...
Apres avoir cree un petit soft pour recuperer des infos d'une badgeuse que ma boite utilise, j'ai adapte mon programme pour faire la meme chose sur les boitiers de Telephonie par Internet de chez Sipura/LinkSys.
VoIP Tracker Lite est donc ne.
Le probleme c'est que j'ai un utilisateur sous Mac Intel pour qui ca plante. D'apres le crash log, ca ressemble a un probleme d'allocations memoire :
Le truc que je comprends pas bien, c'est que si l'utilisateur force mon appli a utiliser Rosetta ... tout baigne.
J'aurais penser qu'un probleme d'allocation memoire n'est pas specifique a l'architecture ... j'ai loupe un episode ou quoi ?
VoIP Tracker Lite est donc ne.
Le probleme c'est que j'ai un utilisateur sous Mac Intel pour qui ca plante. D'apres le crash log, ca ressemble a un probleme d'allocations memoire :
Exception: EXC_BAD_ACCESS (0x0001)<br />Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0e2ffff0<br /><br />Thread 0 Crashed:<br />0 <<00000000>> 0xffff0f26 __memcpy + 1926 (cpu_capabilities.h:228)<br />1 com.apple.CoreFoundation 0x9080c44c __CFStringCreateImmutableFunnel3 + 1757<br />2 com.apple.CoreFoundation 0x90817938 CFStringCreateWithSubstring + 585<br />3 com.apple.Foundation 0x927e39ee -[NSCFString substringWithRange:] + 185<br />4 ...rkhatsoft.VoIP Tracker Lite 0x00003a2b -[HDSPAHelperTools parseScanEngine:skippinguntil:capturinguntil:] + 230<br />5 ...rkhatsoft.VoIP Tracker Lite 0x00003598 -[HDSPAHelperTools probeVOIPDevice:voipSettingsObject:] + 681<br />6 ...rkhatsoft.VoIP Tracker Lite 0x00002819 -[HDSPAHelperAppController startRegularProbe:] + 165
Le truc que je comprends pas bien, c'est que si l'utilisateur force mon appli a utiliser Rosetta ... tout baigne.
J'aurais penser qu'un probleme d'allocation memoire n'est pas specifique a l'architecture ... j'ai loupe un episode ou quoi ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pas forcément, ça peut venir de l'utilisation d'un pointeur qui est à une valeur idiote également. C'était un bug courant en Pascal.
Il y a des différences de traitements des exceptions du proc entre ppc et intel (par exemple, la division par 0 qui plante un prog intel, mais qui ne fait rien sous ppc).
Ici, le crash log suggère :
- soit un problème d'allocation mémoire (plus assez de ram par exemple).
- soit des paramètres passés à memcpy qui sont tarés.
Dans le second cas, il faut revenir à ce qui est utilisé comme range dans le -[NSCFString substringWithRange:] (des valeurs du range qui sont bizarres peuvent conduire à un mauvais calcul des pointeurs lors de l'allocation du buffet qui servira de résultat au substring).
.
Miam!
probeVoIPDevice commence par contacter le boitier, virer les balises HTML et lance le parsing via parseScanEngine. Le tout est stocke dans un NSDic.
Je me dis que soit c'est mon parsing qui deconne (mais alors pourquoi j'ai qu'un seul utilisateur Intel qui s'en plaint, c'est encore un mystère) ou c'est mes release.
Je vais continuer à chercher, si vous avez des idées je suis preneur
[tt]if (xmlConversionDocument == nil || theError == NULL)[/tt] ???
Tu as un problème (et tu dois alors retourner @error *) si, soit xmlConversionDocument est nil en effet... soit si theError n'est pas NULL mais est une NSError avec un code d'erreur et un message et tout, non ?
S'il y a eu une erreur, il te retourne ladite erreur dans theError, donc theError != NULL, donc le contraire de ton test...
Enfin moi ce que j'en dis...
*Entre nous, retourner la chaà®ne @error pour indiquer une erreur c'est moyen comme concept de gestion des erreurs. Mais bon, passons.
Effectivement Ali, c'est un peu le contraire que mon test devrait faire... je vois vraiment pas pourquoi j'ai laisse ca comme ca ... un peu trop de
Pour ce qui est de @error c'est effectivement un peu spartiate. Pour le moment si @error est retourne, un message d'erreur s'affiche indiquant qu'il y a un probleme pour contacter le boitier.
C'est un peu generique, mais c'est ce que j'ai trouve de plus parlant pour l'utilisateur (NSError retourne "zero byte ressource" sinon)
Ca semble plus rapide et ca ne plante plus MAIS (ben oui faut bien un mais) les infos ne s'affiche pas correctement (pas de soucis sous Rosetta/PPC).
Parce que là bon, on n'est pas devins quoi.
Avant (qui plante sur x86 mais fonctionne sous PPC)
Après (qui plante plus sous x86 mais n'affiche pas les bonnes valeurs)
Quand je teste sur mon MacPPC j'ai pas de soucis, mais un de mes utilisateurs Mac x86 se retrouve avec des champs ayant tous la même valeur. Après avoir fouillé un peu il semble que cela puisse venir du fait que si mon parseScanEngine retourne nil, NSDictionary s'emmêle les crayons.
Je vais donc rajouter un test et croiser les doigts ... Si quelqu'un avec un Mac Intel et un boitier LinkSys/Sipura se sent l'âme d'un testeur, qu'il m'envoie un PM.
Encore merci de votre aide.
J'ai remplacé mon Parser maison par celui de NSXMLDocument. Un fichier html + Tidyhtml = XHTML donc on peut utiliser objectsForXquery pour recolter les infos.
C'est un chouille plus lent mais beaucoup plus simple. Pour ceux que ça interesse encore :