كيفيةالتصحيح

From The Document Foundation Wiki
Jump to: navigation, search

خيارات التصحيح (اكتشاف العلل)

لعمل أي تصحيح تفاعلي يجب عليك أولاً تمكين الدعم لتصحيح. لتمكين دعم التصحيح لكامل بناء LibreOffice: ./autogen.sh --enable-debug

او يمكنك تمكينه لوحدة محددة: "--enable-debug=sw/ xmloff/"

يوجد العديد من الخيارات المفيدة للتصحيح، منها: --enable-dbgutil والذي يوفر لك شفرات تصحيح إضافية مع ( اكثر/اقل ) من التوكيدات، بالإضافة إلى نمط التصحيح ( STL ) الخاص بمكتبة ( ++libstdc ) على بعض منصات ( GCC ).
كما يمكنك استخدام الخيار: --enable-debug مع الخيار السابق والذي يعتبر مستقل عنه.


يوجد ايضا الخيار: --enable-symbols والذي ليس بذي نفع للتصحيح التفاعلي، لأنه فقط يتيح للمترجم اصدار رموز التصحيح، كما لا يعطل الاستمثال، فبتالي سيكون التنقل بين اوامر وتعليمات الشيفرة المصدرية صعباً.


يجب عليك الانتباه الى ان المساحة التي يحتاجها بناء LibreOffice بشكل كامل مع استخدام احد الخيارين: --enable-symbols او --enable-debug لجميع الوحدات يحتاج إلى أكثر من 20 جيجا من مساحة القرص الصلب. اذا وجدت ان المساحة اكبر مما ترغب يمكنك بعد الانتهاء من بناء LibreOffice (مع عدم تمكين خيارات التصحيح) إعادة بناء الوحدات التي ترغب فيها مع خيار التصحيح.

للإصدار 3.5، يمكنك إعادة بناء وحدة واحدة مع خيار التصحيح بهذه الطريقة: cd <module> && make -sr clean && make -srj4 debug=t

اما للإصدارات الاحدث (3.6 فما فوق) تستخدم هذه الطريقة: make <module>.clean && make <module> debug=t


التصحيح باستخدام (gdb)

هناك طريقتان: يمكنك بدء LibreOffice باستخدام برنامج نصي مخصص ( soffice، swriter، إلخ ) ومن ثم ربط المصحح بعمليات LibreOffice، او يمكنك بدء LibreOffice بصيغته الثنائية ( soffice.bin )مباشرة من المصحح.
في الملاحظات التالية المتغير $LOROOT يمثل المسار الى المجلد المستنسخ فيه مخزون ( git ) المركزي، حيث يؤدي هذا المسار إلى المجلد الحاوي على الشفرات النصية ( autogen.sh ).


الارتباط بعملية ( soffice.bin )

الطريقة الاولى اكثر بساطه، لان الشفرات النصية ستهتم بإعداد كافة متغيرات البيئة المطلوبة:

$ cd $LOROOT/install/program
$ ./sdraw    # or ./soffice ./swriter, ...
$ LOPID=$(pidof soffice.bin)
$ gdb soffice.bin $LOPID
(gdb)

عند تنفيذ احد البرامج النصية :( soffice، swriter، sdraw، ... ) يمكنك تمرير الخيار -norestore والذي سيدعم ( إعادة التشغيل/الاستعادة ) بعد الأخطاء الفادحة.
لربط وفصل عملية من داخل قشرة ( gdb ) يمكنك الاستفادة من الاوامر: attach <pid> و detach ، الامر الاخير لا يحتاج لأي معطيات.

بعد حدوث الربط مع عملية ( soffice.bin ) سيقوم ( gdb ) بإيقاف البرنامج.


بدء LibreOffice من المصحح (gdb)

اسهل طريقه للإصدار 3.5 والاصدارات الاحدث من LibreOffice هي باستخدام امر بسيط ينفذ على المستوى الاعلى :

 make debugrun


للإصدارات الاقدم: تحتاج -على الاقل- إلى مصدر الملف ( ooenv ):

$ cd $LOROOT/install/program
$ source ./ooenv
$ gdb ./soffice.bin
(gdb) run -impress (or -writer, ...)
(gdb)

سيبدأ ( Impress )بالعمل، ولكنه لن يتوقف ، لذا يجب عليك قبل تنفيذ امر run تعين "نقاط التوقف".

في حال احتجت إلى إعداد متغيرات اكثر للبيئة نصيحتي هي أن تنظر داخل الشفرات النصية المنفذة soffice إذا رغبت في توقف البرنامج عند الدالة “main” يجب عليك استخدام الامر start عوضا عن الامر run ، كلاهما سيقوم بتمرير المعطيات إلى المحتوى التنفيذي ( soffice.bin ).



" gdb primer "

عند توقف البرنامج يمكنك البحث عن الرموز، مشاهدة البيانات وإعداد نقاط التوقف:

(gdb) info fun DrawEllipse
All functions matching regular expression "DrawEllipse":

File $LOROOT/svtools/source/filter.vcl/wmf/winmtf.cxx:
void WinMtfOutput::DrawEllipse(Rectangle const&);

File $LOROOT/clone/libs-gui/vcl/source/gdi/outdev5.cxx:<span style="color:#000000" />
void OutputDevice::DrawEllipse(Rectangle const&);

File $LOROOT/clone/libs-gui/vcl/source/gdi/pdfwriter.cxx:
void vcl::PDFWriter::DrawEllipse(Rectangle const&);

Non-debugging symbols:
0x00007f826dd4a318  OutputDevice::DrawEllipse(Rectangle const&)
0x00007f826dd4a318  [mailto:_ZN12OutputDevice11DrawEllipseERK9Rectangle@plt _ZN12OutputDevice11DrawEllipseERK9Rectangle@plt]

(gdb) break  vcl::PDFWriter::DrawEllipse
Breakpoint 1 at 0x7f826c7c5e20: file /opt/shared/work/source_code/libreoffice/libo/clone/libs-gui/vcl/source/gdi/pdfwriter.cxx, line 159.

الآن تم تعيين نقطة توقف في الموقع المتصل بدالة معينة. مع ملاحظة ان إسم (الدالة او الطريقة) يجب ان يكون صحيح وتام ويحتوي على اسم الفئة"class" و مساحة الاسم "namespaces".
بناء الجملة العام: break <location> ، حيث ( <location> ) يمكن أن يكون اسم تام و مؤهل بالكامل لدالة، أسلوب، عنوان ذاكرة أو اسم لملف متبوع بـ ":" ورقم السطر. لمزيد من التفاصيل حول مفهوم الموقع تفضل بزيارة صفحة دليلgdb Specifying a Location

لعرض قائمة بنقاط التوقف التي سبق وانشأتها، قم بعمل التالي:

(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00007f826c7c5e20 in vcl::PDFWriter::DrawEllipse(Rectangle const&)
                                               at /opt/shared/work/source_code/libreoffice/libo/clone/libsgui/vcl/source/gdi/pdfwriter.cxx:159

لإزالة نقطة توقف يمكنك استخدام أحد الأوامر التالية:

clear <location>
delete <breakpoint number>




نقاط التوقف المعلقة

في حال كان الرمز المعطى متعلق بمكتبة مشتركة لم يتم تحميلها بعد يمكنك ان تضيف نقطة توقف مرتبطة بهذا الرمز، وسيقوم ( gdb ) بتعامل معها كنقطة توقف معلقة ، ثم يقوم بتنشيطها عند توفر الرمز.

(gdb) break SVGActionWriter::ImplWriteRect
Can't find member of namespace, class, struct, or union named "SVGActionWriter::ImplWriteRect"
Hint: try 'SVGActionWriter::ImplWriteRect<TAB> or 'SVGActionWriter::ImplWriteRect<ESC-?>
(Note leading single quote.)
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (SVGActionWriter::ImplWriteRect) pending.
(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  SVGActionWriter::ImplWriteRect

اذا كنت ترغب بأن يقوم ( gdb ) بانشاء نقطة توقف معلقة ترتبط باي رمز غير معروف تلقائيا دون ان يسألك ما المطلوب فعله في كل مره، يجب عليك تفيذ الامر التالي:

set breakpoint pending on

للعودة إلى الحالة الإفتراضية اعد تعينه إلى “auto”.

تتمثل الصعوبة في التعامل مع نقاط التوقف المعلقة في تذكر الاسم الصحيح و التام ( الذي يحوي على اسم الفئة"class" و مساحة الاسم "namespaces" ) للدالة او الاسلوب. الامر: info fun لن يساعدك لأن الرمز لا يزال مجهولا.

احد الحلول الممكنه هو بستخدام احداث الكائن المشترك( shared object events ).



تفريغ سلسة نصية

من خلال سحر الطباعة الجيدة الخاصة بـ ( gdb ) و ( gdb 7) وما بعده، ستقوم السلسلة النصية المطبوعة بتفريغ محتوى السلسلة النصية بغض النظر عن نوعها( UTF-16 rtl::OUString / 8-bit rtl::OString)

تدعم الطباعة الجيدة الافراغ السليم لمجموعة متنوعة من الكائنات الاخرى بالضافة الى السلسة النصية، مثل: ( Any, Sequence, Date, Time,...) في حال احتجت لرؤية البنية بدون استخدام الطباعة الجيدة استخدم : print/r او p/r . الطباعة الجيدة نشطة تلقائيا للتصحيح التلقائي و ( dev-install ).



تفريغ حاويات ( STL )

يستطيع ( GDB ) تطبيق الطباعة الجيدة على محتوى حاويات ( STL )، وهذا امر مفيد للغاية. لكن من الممكن ان لا يعمل خارج الصندوق لان مجموعة تثبيت ( LO ) تحوي على ( ++libstdc ) الخاصة بها، لذلك لن يتمكن ( gdb ) من تحميل ملفات( Python ) ذات الصلة تلقائيا.

على نظام فيدورا 16، الإضافة التالية لـ ( .gdbinit ) تحل المشكلة ( قد تحتاج الى تكيف ارقام الاصدار في نظامك ):

# workaround OOo/LO shipping its own libstdc++
python
import sys
sys.path.insert(0, '/usr/share/gcc-4.6.1/python')
end
source /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.16-gdb.py



احداث الكائن المشترك

احداث الكائن المشترك تحدث في كل مرة يحصل فيها تحميل او افراغ لمكتبة مشتركة. هي غير نشطة بشكل افتراضي، ولكن يمكنك تشغيله باستخدام الأمر التالي:

set stop-on-solib-events 1

الان في كل مرة يتم فيها تحميل مكتبة مشتركة سيتوقف البرنامج وستتمكن من البحث عن رموز جديدة و وضع نقاط توقف.

يجب عليك تفعيل احداث الكائن المشترك فقط عندما تعلم أن المكتبة المشتركة، المهتم فيها ، سيتم تحميلها في وقت قصير، لأنه في حال استغرقت وقت طويل سيتوجب عليك استخدام الامر: continue بكثرة مما سيسبب ازعاج لك.

كيف يمكنك معرفة ما إذا كانت المكتبة المشتركة المرغوب فيها تم تحميل؟ يمكنك استخدام الامر : info shared <reg expr> لمعرفة ذلك. سيقوم هذا الأمر بعرض قائمة بجميع المكتبات المشتركة التي تم تحميلها والتي تطابق التعبير العادي.

للمساعدة


Misc helpers

بعض ملحقات( gdb ) التي قد تكون مفيدة في بعض الظروف:

  • fcatch: يتوقف عند طرح استثناء، إذا و إذا فقط كان في المكدس دالة معينة.



التصحيح باستخدام " DDD " ( الواجهة الامامية لـ "gdb" )

إذا كنت ترغب في إرفاق المصحح لعملية soffice.bin عليك اولا بدء LibreOffice

$ cd $LOROOT/install/program
$ ./soffice    # or ./swriter, ./simpress, ...

في حال كنت تريد بدء LibreOffice من المصحح، تحتاج قبل تشغيله إلى مصدرية متغيرات البيئة :

$ cd $LOROOT/install/program
$ source ./ooenv

واخيرا يمكنك بدء "DDD" باستخدام الامر: ddd

في كلا الحالتين ستحتاج الى اعداد البرنامج ليتم تصحيحه، انقر على Open Program ثم ادخل قائمة File. ستظهر لك نافذة حوار: حدد soffice.bin والذي ستجده تحت $LOROOT/install/program. في حال بدأت LibreOffice بالفعل ستحتاج إلى إرفاق عملية soffice.bin: تستطيع القيام بذلك من خلال File>Attach to process. ستظهر لك قائمة بالعمليات قيد التشغيل، انقر نقرة مزدوجة على العملية soffice.bin ( ينبغي ان تكون محددة بالفعل ). و لفصل عملية نستخدم نفس الطريقة و بتنفيذ الأمر File>Detach.

بعد الإرفاق بالعملية سيتم تعليق البرنامج وبتالي يمكنك البدء بتصحيحه. سوف يفتح تلقائيا صندوق ادوات الاوامر . في الجزء السفلي من الإطار يمكنك رؤية وحدة تحكم GDB : قشرة ( shell ) حيث يمكنك تنفيذ اوامر "gdb" مباشرة. فوق وحدة التحكم GDB توجد نافذة المصدر حيث يمكنك إلقاء نظرة على برنامج الشفرات المصدرية.

لتغيير نوع الخط وحجم وحدة التحكم GDB ونافذة المصدر اذهب إلى Edit>Preferences...>Fonts ثم عدل خاصية Fixed Font. لجعل التخصيصات الخاصة بك دائمة يجب عليك اختيار Save Options في قائمة Edit .

لبدء LibreOffice من المصحح انقر على زر Run في صندوق ادوات الاوامر. أو يمكنك إعطاء الامر run او start مباشرة من وحدة تحكم GDB، هذا سيمكنك من ارسال معطيات الى البرنامج.

Status>Backtrace سيفتح لك مربع حوار يحوي على سلسلة من نداءات الدوال: تبدأ من نداء الدالة الرئيسية إلى نداء اخر دالة: الدالة حيث توقف البرنامج.



نقاط التوقف المعلقة

نقاط التوقف المعلقة غير مدعومة من قبل ( DDD ). يمكنك التحايل على ذلك بتعين خاصية breakpoint pending على وضع "on" ( الوضع الافتراضي هو "auto" ) يمكنك القيام بذلك من خلال تنفيذ الامر set breakpoint pending on في وحدة تحكم GDB او من الخيارات ذات العلاقه في GDB Settings : (Edit>GDB Settings ...).
الان باسخدام الزر Break يمكنك إعداد أي سلسلة محارف صحيحة بوصفها نقطة توقف ( معلقة او غير معلقة ). خذ حذرك عند القيام بهذا.



احداث الكائن المشترك

لتمكين احداث الكائن المشترك استخدم الامر: set stop-on-solib-events 1 في وحدة التحكم GDB او اختر Stopping for Shared Library Events من GDB Settings.



الملفات حرة المصدر

يمكنك البحث عن ملفات المصدر من خلال مربع الحوار Open Source (File>Open Source...) . لمزيد من التفاصيل حول مميزات مربع حوار " Open Source " انقر على الزر Help.


التصحيح باستخدام " WinDbg " ( على انظمة ويندوز )

يرجى الاطلاع على صفحة : How to get a backtrace with WinDbg.


تعطيل المخصص لـ " memcheck "

بشكل افتراضي يستخدم LibreOffice مخصص لذاكرة، لذلك لن يستطيع ( valgrind ) اعطاء نتائج كاملة إلا بتعطيله، لتعطيله اثناء وقت التشغيل...

$ export G_SLICE=always-malloc

يمكن ايضا تعطيله في وقت الإنشاء:

$ ./autogen.sh --with-alloc=system



تصحيح اختبار " cppunit "

في وقت البناء، اذا تعطل اختبار ( cppunit ) يمكنك الحصول على المصحح هناك باستخدام:

$ export GDBCPPUNITTRACE="gdb --args"

الآن عند بناء ( gdb ) ستبدأ بتحميل اختبار ( cppunit )، اكتب "تشغيل" لتنفيذ الاختبار تحت ( gdb ).

كبديل، إذا تعطل الاختبار وكان هناك استثناء ( غير ملتقط ) يمكنك تتبع الاختبار لمعرفة من اين تم طرح الاستثناء :

$ export DEBUGCPPUNIT=TRUE

والذي سيقوم بتسجيل الاستثناءات و اللاقطات في ( gdbtrace.log ).


Valgrinding (memcheck) cppunit tests

في وقت البناء يمكنك ( memcheck ) اختبار ( cppunit ) و الاختبارات الاخرى بتنفيذ:

$ export VALGRIND=memcheck

وهذا تلقائيا سيضع ( G_SLICE=always-malloc ) و بتالي سيعمل كل من اختبار ( cppunit ) و اختبار ( hunspell regression )تحت ( valgrind ) مع ( tool=memcheck-- )



Valgrinding (memcheck) LibreOffice itself

$ export VALGRIND=memcheck

وهذا تلقائيا سيضع ( G_SLICE=always-malloc ) مما سيسبب عمل LibreOffice تحت ( valgrind ) مع ( tool=memcheck-- )


Valgrinding (helgrind) cppunit tests

في وقت البناء يمكنك ( helgrind ) اختبار ( cppunit ) و الاختبارات الاخرى بتنفيذ:

$ export VALGRIND=helgrind


Valgrinding (helgrind) LibreOffice itself

$ export VALGRIND=helgrind

هذا سيؤدي لعمل LibreOffice تحت ( valgrind ) مع ( tool=memcheck-- ).


تشغيل الاختبارات اللاحقة " subsequent tests "

make check ) من المستوى الاعلى ستنفذ بناء كامل، ومن ثم عمل كافة الاختبارات اللاحقة ( subsequent tests )، بينما ( make subsequentcheck ) من المستوى الاعلى ستقوم بتشغيل كافة الاختبارات اللاحقة( subsequent tests ) فقط.

يمكنك تشغيل اختبار لاحق واحد عبر هدفه، مثال: make cmd cmd='(cd sw && make -rs $(WORKDIR)/JunitTest/sw_complex/done)' .



تصحيح الاختبارات اللاحقة " subsequent tests "

يوجد سجل للاختبارات الفاشلة، يمكنك الاطلاع عليه من خلال محرر النصوص:

workdir/unxlngx6/JunitTest/<module>_complex/done.log

لتصحيح، الامر التالي سيقوم بالبدء بتنصيب LibreOffice من الحالّ make dev-install ) داخل ( gdb ):

make debugrun 

اولا قم بإزالة ( gdb TUI ) باستخدام ( C-x a )، ثم عيين نقطة توقف عند الاسلوب ( offending )، ثم تشغيل، سيظهر لك مركز البداية. ثم يمكنك تشغيل الامر التالي ( في طرفية اخرى ):

make gb_JunitTest_DEBUGRUN=T <module>.subsequentcheck

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



تصحيح الاختبارات ( qadevOOo / unoapi ) اللاحقة

اختبار ( qadevOOo / unoapi ) صعب بعض الشيء في التصحيح.

اذا فشل الاختبار يجب علينا اولا معرفة أي اسلوب هو المسؤول عن هذا الفشل، قم بفتح الملف التالي بواسطة محرر النصوص:

workdir/unxlngx6/JunitTest/<module>_unoapi/done.log

في نهايته ستجد الملخص التالي، والذي يشير إلى المكون المسبب للفشل:

Failures that appeared during scenario execution:
         toolkit.AccessibleStatusBarItem
1 of 53 tests failed

البحث عن ( FAIL ). هذا سيظهر خطأ مثل:

LOG> getCharacterBounds(6)
:LOG> Text at this place  
LOG> Character bounds outside component
LOG> Character rect: 43, -566, 0, 0
LOG> Component rect: 91, 2, 71, 18
Method getCharacterBounds() finished with state FAILED
LOG> getCharacterBounds(): PASSED.FAILED

إذا قمت بتمرير إلى الأعلى ستشاهد مثل هذا السطر:

 checking: [toolkit.AccessibleStatusBarItem::com::sun::star::accessibility::XAccessibleText] is iface
[com.sun.star.accessibility.XAccessibleText] testcode: [ifc.accessibility._XAccessibleText]:

و الذي يشير إلى شفرة الاختبار بالجافا الذي يتم تنفيذه هنا: ifc.accessibility._XAccessibleText المتوافق مع qadevOOo/tests/java/ifc/accessibility/_XAccessibleText.java. أيضا يوجد شفرة اعداد بالجافا مخصصة لمكون اختبار toolkit.AccessibleStatusBarItem في qadevOOo/tests/java/mod/_toolkit/AccessibleStatusBarItem.java.

قلل من الاختبار قليلا لزيادة السرعة: قم بتعديل على ملف السيناريو المتوافق، المسمى عادة: <module>/qa/unoapi/<module>.sce،قم بإزالة كل شيء باستثناء السطر الذي يتوافق مع اختبار الفشل، هنا AccessibleStatusBarItem، وتحقق اذا ما زال فاشل.

الان الجزء الصعب هو معرفة المكان الذي ينفذ فيه الاسلوب المسبب للفشل; غالبا ( على سبيل المثال: Writer ) يكون اسم الفئة مماثل او مشابه لحد كبير اسم مكون الاختبار، ولكن في هذا المثال: checkCharacterBounds من المدهش انها ليست في وحدة (toolkit)، ولكن git grep تشير الى accessibility/source/standard/vclxaccessiblestatusbaritem.cxx، الحاوي على الاسلوب VCLXAccessibleStatusBarItem::getCharacterBounds

بمجرد عثورك على هذه المعلومات، اكمل مع ( make deubgrun ) وغيرها. كما هو موضح في القسم السابق ( تصحيح الاختبارات اللاحقة " subsequent tests " ).


البحث عن تلف في الذاكرة على انظمة ويندوز باستخدام " DrMemory "

إذا كان لديك علة خطيرة على ويندوز، وكان تتبع المكدس

داخل ( malloc / free / new / delete )فانه على الأرجح لديك
تلف في الذاكرة. لمثل هذه الحالات توجد اداة لأنظمة ويندوز تسمى ( DrMemory ); يمكنك الحصول عليها من:  http://www.drmemory.org/

يجب عليك تثبيته مع الحصول على بناء ويندوز مع رموز التصحيح من: http://dev-builds.libreoffice.org/win32-debug/

ثم يجب عليك الحصول على وحدة تحكم من نوع ما، من اجل ان تعمل هذه الاداة بشكل صحيح يجب عليك تنفيذ الامر:

drmemory -no_count_leaks -ignore_asserts -no_check_gdi -no_check_uninitialized -- soffice.exe

نتوقع أن يكون بطيء، وهذا أمر طبيعي :-) . نأمل في نهاية اليوم، ان تعود علتك بـ:


Error #7: UNADDRESSABLE ACCESS: writing 0x2b9ca0f4-0x2b9ca0f8 4 byte(s)

سجل الخطأ، وهو خطأ جسيم وتتبع مفيد جدا له


يوجد ايضا الخيار: --enable-symbols والذي ليس بذي نفع للتصحيح التفاعلي، لأنه فقط يتيح للمترجم اصدار رموز التصحيح، كما لا يعطل الاستمثال، فبتالي سيكون التنقل بين اوامر وتعليمات الشيفرة المصدرية صعباً.


يجب عليك الانتباه الى ان المساحة التي يحتاجها بناء LibreOffice بشكل كامل مع استخدام احد الخيارين: --enable-symbols او --enable-debug لكافةالوحدات أكثر من 20 جيجا من مساحة القرص الصلب. اذا وجدت ان المساحة اكبر مما ترغب يمكنك بعد الانتهاء من بناء LibreOffice (مع عدم تمكين خيارات التصحيح) إعادة بناء الوحدات التي ترغب فيها مع خيار التصحيح.

للإصدار 3.5، يمكنك إعادة بناء وحدة واحدة مع خيار التصحيح بهذه الطريقة: cd <module> && make -sr clean && make -srj4 debug=t

اما للإصدارات الاحدث (3.6 فما فوق) تستخدم هذه الطريقة: make <module>.clean && make <module> debug=t



تصحيح دورة حياة " C + + UNO "

يتم تخزين عدد المؤشرات كـ ( m_refCount )، على سبيل المثال: اضافة مراقب الى الدالة الإنشائية الخاصة بالكائن من نوع ( UNO ) لمعرفة من الذي يأخذ ملكية مشتركة للكائن.

(gdb) watch * (&m_refCount)



تأكيدات و تسجيل الدخول

انظر الى: Development#Assertions and Logging.



متغيرات البيئة

  • ( SAL_NO_MOUSEGRAPS=1 ), يمنع LibreOffice من الاستيلاء على الفأرة أثناء التصحيح



تحكم وحدات الماكرو بشفرات التصحيح

  • وحدة الماكرو NDEBUG هو الطريقة القياسية للتحكم في وظائف code>assert القياسية.

تم تعريفه في البناء الانتاجي، وتم تركه غير معرف لـ ( --enable-debug/--enable-dbgutil ). (نلاحظ أن تعريفه يقوم بتعطيل التأكيدات).

  • وحدات الماكرو SAL_LOG_INFO و SAL_LOG_WARN تتحكم في ما اذا كان يتم تفعيل وظيفة SAL_INFO و SAL_WARN من sal/log.hxx. لم يتم تعريفه في البناء الانتاجي، وتم تعريفه في ( --enable-debug/--enable-dbgutil ). إذا فعلة، يتم التحكم في سلوكها وقت التشغيل بواسطة متغير البيئة SAL_LOG ( راجع الوثائق الموجودة في sal/log.hxx للحصول على مزيد من التفاصيل ).
  • وحدة الماكرو DBG_UTIL من الممكن ان تمكن شفرات اضافية من المحتمل ان تؤثر على توافق ( ABI )، وتغير هيكلة البيانات العامة. ( لن تستطيع القيام ببناء جزئي لLibreOffice عن تمكينه ). لم يتم تعريفه في البناء الانتاجي، وتم تعريفه في --enable-dbgutil .


  • وحدة الماكرو _GLIBCXX_DEBUG تمكن تأكيدات مفيدة في libstdc + + STL، والتي تؤثر على توافق ( ABI ); يتم ايضا تمكينها بواسطة --enable-dbgutil على ( ELF ) القائمة على منصة ( GCC ).


  • وحدة الماكرو OSL_DEBUG_LEVEL تتحكم في شفرات تصحيح اضافيه ومكلفة ( لكنها لا تؤثر على التوافق ).معرفه في البناء الانتاجي على انها: 0 و 1 في --enable-debug/--enable-dbgutil، و على انها: 2 او اعلى مع المعطى المباشر dbglevel=N إلى make.