سؤال

ما هي التعليمات التي تسبب انقطاعًا شديدًا في Xcode؟على سبيل المثال ضمن Visual Studio يمكنني القيام بـ "_asm int 3" أو "DebugBreak()".في بعض تطبيقات دول مجلس التعاون الخليجي يكون asm("break 0") أو asm("trap").

لقد جربت مجموعات مختلفة ضمن Xcode دون أي حظ.(يعمل المجمّع المضمّن بشكل جيد لذا فهي ليست مشكلة في بناء الجملة).

كمرجع، هذا خاص بتأكيد الماكرو.لا أرغب في استخدام التعريفات الموجودة في Accept.h سواء من أجل قابلية النقل أو لأنها تبدو وكأنها تقوم بعملية abort() في الإصدار الذي يوفره XCode.


جون - ممتاز، في صحتك.كمرجع، فإن بناء جملة int 3 هو المطلوب لأجهزة Intel Mac وiPhone.


كريس - شكرًا على تعليقك ولكن هناك العديد من الأسباب لتجنب وظيفة التأكيد القياسية () لقواعد التعليمات البرمجية المنقولة إلى منصات مختلفة.إذا واجهت مشكلة في تكرار التأكيد الخاص بك، فعادةً ما يكون ذلك بسبب أن لديك وظائف إضافية (التسجيل، وتفكيك المكدس، وتفاعل المستخدم) التي ترغب في الاحتفاظ بها.

اقتراحك بمحاولة استبدال المعالج عبر تطبيق "__assert" أو ما شابه لن يكون قابلاً للنقل.عادةً ما يكون "التأكيد" القياسي عبارة عن ماكرو، وعلى الرغم من أنه قد يتم تعيينه إلى __assert على نظام التشغيل Mac، إلا أنه لا يتم تعيينه على الأنظمة الأساسية الأخرى.

هل كانت مفيدة؟

المحلول

http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeProjectManagement/090_Running_Programs/chapter_11_section_3.html

asm {trap}            ; Halts a program running on PPC32 or PPC64.

__asm {int 3}         ; Halts a program running on IA-32.

نصائح أخرى

يمكنك فقط إدراج مكالمة إلى Debugger() - سيؤدي ذلك إلى إيقاف تطبيقك في مصحح الأخطاء (إذا كان يتم تشغيله ضمن مصحح الأخطاء)، أو إيقافه مع استثناء إذا لم يكن كذلك.

أيضًا، لا تتجنب assert() "لأسباب تتعلق بالنقل" - قابلية النقل هي سبب وجودها!إنه جزء من Standard C، وستجده أينما تجد مترجم C.ما تريد فعله حقًا هو تحديد ملف جديد معالج التأكيد يؤدي ذلك إلى انقطاع مصحح الأخطاء بدلاً من الاتصال abort();تقريبًا جميع مترجمي لغة C يقدمون آلية يمكنك من خلالها القيام بذلك.

عادةً ما يتم ذلك ببساطة عن طريق تنفيذ دالة أو ماكرو يتبع هذا النموذج الأولي:

void __assert(const char *expression, const char *file, int line);

يتم استدعاؤه عند فشل تعبير التأكيد.عادة، لا assert() في حد ذاته، هو ما ينفذ " printf() تليها abort()"هذا هو السلوك الافتراضي الموثق.من خلال تخصيص هذه الوظيفة أو الماكرو، يمكنك تغيير سلوكها.

__builtin_trap();

بما أن Debugger() قد تم استهلاكه الآن، فمن المفترض أن يعمل هذا بدلاً من ذلك.

https://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCONTROLLEDCRASH

للأجيال القادمة:لدي بعض التعليمات البرمجية لإنشاء توقفات في إطار المكدس الصحيح في مصحح الأخطاء و (اختياريًا) إيقاف التطبيق مؤقتًا حتى تتمكن من إرفاق مصحح الأخطاء في الوقت المناسب.يعمل مع جهاز المحاكاة والجهاز (وربما سطح المكتب، إذا كنت في حاجة إليه في أي وقت).مشاركة مفصلة بشكل شامل في http://iphone.m20.nl/wp/2010/10/xcode-iphone-debugger-halt-assertions/

لقد وجدت ما يلي في منتدى أبل:

لا يأتي Xcode مع أي فواصل رمزية مدمجة - لكنها سريعة في الإضافة.انتقل إلى نافذة نقاط التوقف وأضف:

-[رفع NSException]

kill(getpid(), SIGINT);

يعمل في جهاز المحاكاة والجهاز.

هناك أيضًا الوظيفة التالية المتوفرة كبديل Halt()‎ عبر النظام الأساسي:

#include <stdlib.h>

void abort(void);

نحن نستخدمه في محركنا متعدد المنصات لتنفيذ iPhone في حالة التأكيدات القاتلة.منصة مشتركة عبر Nintendo DS/Wii/XBOX 360/iOS وما إلى ذلك...

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top