شكرًا على الإبلاغ عن هذا ، سأضطر إلى إلقاء نظرة فاحصة.

أنا آسف جدًا لأن الأمر استغرق وقتًا طويلاً للعودة إلى هذا @ mvo5 ، وأنا أقدر صبرك.

لتوضيح الأمور قليلاً ، يبدو db.c الحالي ذي الصلة: db_col_db_add () كما يلي:

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... أعتقد أن الإصدار أعلاه في تقرير المشكلة الأصلي كان نسخة مصححة محليًا للتغلب على المشكلة. ومع ذلك ، فإن تغيير الخطأ الذي تم إرجاعه هنا يبدو معقولاً ؛ كنا نستخدم EDOM في بعض الكودات الأخرى على الأقل ، هل يبدو ذلك معقولًا بالنسبة لك؟

ما رأيكmheon؟

يبدو أنه يجب علينا أيضًا تحديث db.c: db_col_merge () أثناء تواجدنا فيه.

من وجهة نظر واجهة برمجة التطبيقات ، أعتقد بالتأكيد أنه من المنطقي إجراء التغيير - التحميل الزائد على أكواد الخطأ يمثل دائمًا مشكلة بالنسبة لتصحيح الأخطاء.

من ناحية libseccomp-golang ، لا ينبغي أن يتطلب ذلك أي تغييرات في التعليمات البرمجية ، طالما تم الحفاظ على اصطلاح ERRNO السلبي ؛ ربما بضعة أسطر من التعليقات على AddArch لشرح معنى الخطأ الجديد ، لذلك ستكون وثائق API كاملة.

لا يزال Travis يعمل قديمًا جدًا من النواة ، وبالتالي فشل الاختبار رقم 47 مرة أخرى. كما ذكر pcmoore منذ فترة ، سأحاول إضافة بعض الذكاء للاختبار لتجنب ذلك.

بخلاف ذلك ، كل شيء آخر من هذا التغيير يبدو جيدًا في كتابي

drakenclimber أعتقد أنك تقصد اختبار 46 ، وليس 47 ، أليس كذلك؟

قبل بضعة أشهر أضفت فحص مستوى واجهة برمجة التطبيقات للاختبارات الحية ، لكنني لا أعتقد أننا بحاجة إلى ذلك من أجل اختبارات bpf-sim ، أليس كذلك؟ اختبارات bpf-sim كانت نظيفة ...؟

ترافيس يتقيأ بالتأكيد في الاختبار رقم 47 (KILL_PROCESS) للتشغيل أعلاه. لقد رأيت أيضًا نفس الفشل على رأس السيد هذا الصباح عندما دفعته إلى فرع منفصل كاختبار للعقل.

اختبار 47-live-kill_process ٪٪ 001-00001 النتيجة: FAILURE 47-live-kill_process 3 KILL_PROCESS rc = 12

لقد تحدثنا عن هذا منذ فترة طويلة ، لذلك قد تكون ذاكرتي ضبابية ، لكنني اعتقدت أن Travis كان لديه مشكلات في اختبار KILL_PROCESS لأن نواة Travis أقدم من 4.14 عندما تم تقديم هذه الميزة.

أم أنني مجنون ... وأتذكر تماما؟

حسنًا ، هل ننظر إلى نفس السجل؟ أنا أنظر إلى البناء وسجل أدناه:

• https://travis-ci.org/drakenclimber/libseccomp/builds/488643921
• https://api.travis-ci.org/v3/job/488643923/log.txt

... التي تُظهر النتائج التالية (تم نسخ اختبارات "c" هنا فقط ، وكانت نتائج "python" هي نفسها):

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... ونعم ، تواجه النوى القديمة مشكلة في بعض الاختبارات الحية ، ولكن كان يجب إصلاح ذلك في 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW ، آخر إصدار من Travis على الفرع الرئيسي كان نظيفًا:

• https://travis-ci.org/seccomp/libseccomp/builds/431949896

لقد قمت للتو بتشغيل بناء جديد باستخدام الفرع الرئيسي فقط للتحقق من أن كل شيء على ما يرام مع Travis:

• https://travis-ci.org/seccomp/libseccomp/jobs/488759868

أعترف أنني الآن مرتبك حقًا. يظهر الارتباط الخاص بك بالتأكيد أن الاختبار رقم 46 هو المشكلة. ولكن عندما أنقر على رابط "Raw Log" في الزاوية اليمنى العليا ، يخبرني أن # 47 فشل. بالنسبة للرابط الذي أدرجته أعلاه ، إليك المكان الذي أعاد فيه السجل الأولي توجيهي:

• https://api.travis-ci.org/v3/job/488643923/log.txt

إذا نظرنا عن كثب ، أعتقد أننا على حق.

46 بإرجاع ERROR كما أشرت. و # 47 يعيد FAILURE (وهو ما كنت أبحث عنه في الأصل.)

وهذا واضح في الملخصات أيضًا:

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0

أنا قادر على إعادة إنتاج مشاكل TravisCI على أحد أنظمتي إذا قمت بالتمهيد إلى نواة 3.x. ينتهي الاختبار 46 بوجود مشاكل في sys_chk_seccomp_action () . يؤدي هذا في النهاية seccomp_init () لإرجاع سياق NULL إلى الاختبار.

أتخيل أن مشكلات Test 47 متشابهة ، لكنني لم أتحقق من مسار فشلها. (على الرغم من أن التغيير pcmoore تمت إضافته للتحقق من أن واجهة برمجة التطبيقات كان يجب أن تمنع هذا. هممم ...)

سأكون فضوليًا ما الذي تغير على ترافيس للتسبب في ذلك. هل عادوا إلى نواة قديمة حقًا؟ شيء من نهايتنا؟

يبدو أننا سنحتاج إلى إضافة بعض الذكاء إلى اختبارات bpf-sim للتعامل مع هذا الأمر. هل نريد محاكاة عمود واجهة برمجة التطبيقات المضاف إلى ملف الاختبارات * أو القيام بشيء آخر تمامًا؟

نعم ، أنا في حيرة من أمري حول سبب نجاحها كما هو الحال الآن. Ubuntu 14.xx قديم حقًا هذه الأيام ، سأرى ما إذا كان هناك إصدار أحدث متاح على Travis.

يبدو أن Ubuntu 16.04 (Xenial) متاح ، فلنجرب ذلك ...

الالتزام 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 يدفعنا إلى Ubuntu 16.04. أنا أفعل هذا في الفرع الرئيسي ، وليس بصفتي علاقات عامة ، لأنني أريد فرض هذا التبديل ؛ إذا تعطل البناء ، فسنصلحه.

• https://travis-ci.org/seccomp/libseccomp/builds/489230929

يبدو أن هذا الإصدار قد أصلح المشكلة في الاختبارات ، لكن clang وجد للتو تسربًا للذاكرة في خطأ في معالجة مسار الكود. سأصلح ذلك في دقيقة واحدة فقط.

مذهل! شكرا للمساعدة ، pcmoore

حسنًا ، مع الالتزام f8854f990004e71ccb9955c33d88d82cdb97ea42 ، يجب أن يكون لدينا فرع رئيسي لمبنى نظيف. عملت بشكل جيد في فرعي الشخصي ، في انتظار المبنى الرئيسي الآن.

drakenclimber أرى أن لديك تصحيحًا جاهزًا لهذا في سجل المشكلات أعلاه ، لكنني لا أرى العلاقات العامة حتى الآن - هل ما زلت تطارد بعض المشكلات في التصحيح أم أنها جاهزة للعلاقات العامة؟

يجب حل هذا الأمر من خلال الالتزام 4a35b6ea6f7c836734536420c50a2745a9e24c69 ، وإغلاق هذا الآن. إذا وجد أي شخص مشكلة في هذا ، يرجى إعادة فتح هذه المشكلة أو إنشاء مشكلة جديدة.