يتم تصنيف أخطاء XLA إلى مصادر مختلفة لأخطاء XLA. يتضمّن كل مصدر قائمة بسياق إضافي غير رسالة الخطأ، وسيتم إرفاقه بكل خطأ ضمن الفئة.
🚧 يُرجى العِلم أنّ عملية توحيد المعايير هذه لا تزال قيد التنفيذ، لذا لن تتضمّن بعض رسائل الخطأ رمز خطأ بعد.
قد يبدو سجلّ الأخطاء على النحو التالي:
XlaRuntimeError: RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space hbm. Used 49.34G of 32.00G hbm. Exceeded hbm capacity by 17.34G. Total hbm usage >= 49.34G: reserved 3.12M program unknown size arguments 49.34G
JaxRuntimeError: RESOURCE_EXHAUSTED: Ran out of memory in memory space vmem while allocating on stack for %ragged_latency_optimized_all_gather_lhs_contracting_gated_matmul_kernel.18 = bf16[2048,4096]{1,0:T(8,128)(2,1)} custom-call(%get-tuple-element.18273, %get-tuple-element.18274, %get-tuple-element.18275, %get-tuple-element.18276, %get-tuple-element.18277, /*index=5*/%bitcast.8695, %get-tuple-element.19201, %get-tuple-element.19202, %get-tuple-element.19203, %get-tuple-element.19204), custom_call_target=""
الحالات والأخطاء في CHECK
بشكل عام، يمكننا في XLA الإبلاغ عن عمليات التنفيذ التالفة باستخدام آليتَين: الحالات وحالات فشل وحدات الماكرو CHECK.
الحالات مخصّصة للأخطاء غير الخطيرة والقابلة للاسترداد. الافتراض هو أنّ الدالة تعرض النتيجة، ويستمر التنفيذ في المسار الذي يتحقّق فيه المتصل صراحةً من عنصر الحالة الذي تم عرضه. وهي مفيدة للتعامل مع إدخالات المستخدمين غير الصالحة أو القيود المتوقّعة على الموارد.
من ناحية أخرى، تغطي حالات فشل CHECK أخطاء المبرمج أو انتهاكات الثوابت التي لا يجب أن تحدث أبدًا إذا كان الرمز البرمجي صحيحًا. في حال تفعيل CHECK، سيسجّل البرنامج رسالة الخطأ ويتوقف على الفور. ويمكن أن تضمن الاتساق الداخلي، مثل التحقّق من أنّ المؤشر ليس فارغًا قبل إلغاء الإشارة إليه.
رموز الخطأ
إليك قائمة فهرس تتضمّن جميع رموز الأخطاء.