خطاهای 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=""
وضعیت‌ها و خطاهای بررسی
به طور کلی، در XLA می‌توانیم اجرای خراب را با دو مکانیسم علامت‌گذاری کنیم: وضعیت‌ها و بررسی خطاهای ماکرو.
وضعیت‌ها برای خطاهای غیرمهلک و قابل بازیابی در نظر گرفته شده‌اند. فرض بر این است که تابع برمی‌گردد و اجرا در مسیری که فراخواننده صریحاً شیء وضعیت برگشتی را بررسی می‌کند، ادامه می‌یابد. این برای مدیریت ورودی نامعتبر کاربر یا محدودیت‌های منابع مورد انتظار مفید است.
از سوی دیگر، خطاهای CHECK خطاهای برنامه‌نویس یا نقض ثابت‌ها را پوشش می‌دهند که در صورت صحیح بودن کد هرگز نباید اتفاق بیفتند. در صورت فعال شدن CHECK، برنامه پیام خطا را ثبت کرده و بلافاصله خاتمه می‌یابد. این می‌تواند سازگاری داخلی را تضمین کند، مانند بررسی اینکه یک اشاره‌گر قبل از ارجاع مجدد تهی نباشد.
کدهای خطا
در اینجا یک لیست فهرست با تمام کدهای خطا وجود دارد.