كيفيةالتصحيح
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
خيارات التصحيح (اكتشاف العلل)
لعمل أي تصحيح تفاعلي يجب عليك أولاً تمكين الدعم لتصحيح.
لتمكين دعم التصحيح لكامل بناء 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 ) التي قد تكون مفيدة في بعض الظروف:
- معلومات حول الاستبعاد المتبادل ( mutex ): لمعرفة العلاقة بين سلاسل التعليمات و الاستبعاد المتبادل.
- 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/
يجب عليك تثبيته مع الحصول على بناء ويندوز مع رموز التصحيح من: https://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
.