הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
כשעפים על מספר מעבדים
לפני כמה ימים קיבלתי דיווח, שתוכנה פשוטה שעובדת עם CppCMS עפה ב־FreeBSD כשיוצרים עומס. קיבלתי trace של המחסנית, שהיה נראה חשוד ומוזר. ניסיתי לשחזר... הכל היה תקין.
אז הופנית לדיווח על באג ישן וסגור שנראה כשתי טיפות מים דומה לתעופה הזו. אז הבנתי שבכל זאת מדובר במשהו אמתי. פתחתי VirtualBox, הורדתי image של FreeBSD 9.0/64bit ותוך עשר דקות התחלתי לנסות שוב. ללא הועיל. ואז קיבלתי תוכנה שלדוגמה (טריביאלית לחלוטין) שבאמת עפה!
מעמיסים עליה כמה אלפי פניות ומידי פעם אני מקבל תעופה בפניה לאובייקט std::locale - האובייקט שמחזיק מידע על לוקל המערכת ובפרט הקידוד שלה (כדי להוסיף ל־content-type).
צללתי פנימה והתחלתי לחפור - זה היה נראה כמו באג שקשור ל־threading, ניסיתי גרסאות קומפיילר שונות ואופציות שונות - תעופה היה קבועה וברורה.
עכשיו קצת רקע: אובייקט הלוקל הוא אובייקט מאוד יעיל שמנהל הכל עם reference-counting - כך שבפועל קיים אובייקט יחיד ששומר את המידע - אז התחלתי לעקוב אחריו וגיליתי שאם יוצרים עומס על המערכת, האובייקט לא נמחק - או נמחק מוקדם מידי ומיד אחריו באה התעופה.
פה נדלקה לי מנורה אדומה - משהו לא בסדר ב־reference-counting, קרי הוא לא מתבצע בצורה אטומית. הכנתי תוכנית לבדיקה שהעתיקה את האובייקט מיליוני פעמים ממספר חוטים - הכל תקין.
נכנסתי עוד יותר פנימה והתחלתי להדפיס את המונה (שהוצאתי בדרך לא דרך כי הוא private) ואכן - הוא ממש לא יציב, הולך וגדל עם הזמן - קרי, קיבלתי אמות - יש בעיה במונה!
המשכתי לחפור עוד יותר לעומק והגעתי לקוד שמבצע את עדכון המונה ב־libstdc++:
if (__gthread_active_p())
__atomic_add(__mem, __val);
else
__atomic_add_single(__mem, __val);
כאשר המטרה של הקוד היא - אם אנחנו רצים מחוט אחד - אז אפשר לבצע חיבור פשוט וזול, אחרת מנהלים עדכון מונה בצורה אטומית - נכנסתי עם gdb בקוד לדוגמה וגיליתי:
- אם אני לא עושה קישור עם libpthread - הוא תמיד מריץ קוד עבור מערכת עם חוט יחיד.
- אחרת תמיד מבצע פעולה אטומית.
מה הבעיה? הספרייה שלי קשורה ישירות ב־libpthread, אבל התכנה הראשית לא! בלינוקס זה לא מפריע אבל ב־FreeBSD זה לא עובד!
אז הוספתי דגלון -lpthread לתכנה הראשית והבעיה נפתרה ב־100% - המונה הפך ליציב ומתאפס מתי שצריך.
כנראה צריך ללכת לחברה ב־FreeBSD או ב־GCC ולפתוח באג: אם התכנה הראשית לא צריכה להפעיל חוטים באופן ישיר זה לא אומר שהספריות לא עובדות עם החוטים!
זה גם הסביר לי מדוע אותו באג שנסגר בגלל שלא היה ניתן לשחזר אותו, לא השתחזר - כי הבעיה נפתרה כנראה במקרה ע"י קישור ל־libpthread.
כך או אחרת, שמחתי שמצאתי את הבעיה, אפילו שהוא ממש לא הבעיה של ה־framework.
כיצד לא לעשות יוניקוד
הסיפורו של הניסיון להדפיס "שלום" במספר שפות במסוף של חלונות.
http://blog.cppcms.com/post/105
לבנות RPM להרבה הפצות
כשאתה מפתח הפרויקט קוד־פתוח, קל מאוד להפיץ קוד מקור, אבל כשזה מגיע לקבצים בינאריים, זה הופך לבעיה הרבה יותר משמעותית. יש עשרות הפצות, כל אחת מגיע במספר גרסאות שונות ומביא אתה חבילות טיפה שונות. לכן, לאדם אחד זה כמעט ובלתי אפשרי לבנות חבילות לכל הפצה אפשרית.
בזכות debootstrap היה לי יחסית קל לבנות חבילות deb ל־Debian ו־Ubuntu, אבל המצב הרבה יותר מורכב כשמדובר ב־rpm כי אין דרך קלה לשים את הפצת rpm בספריה ולעשות לתוכה chroot.
בהמלצת שגיא בן־עקיבא התחלתי להשתמש ב־Open Build Service של OpenSuse.
האמת, אני מאוד מרוצה! כל מה שצריך זה להעלות Source RPM או קובץ spec, כל השאר ייעשה בצורה אוטומטית: בניה למספר הפצות ופלטפורמות, הכנת מקורות מסודרים ואפילו אתה מקבל repository מסודר.
בצורה כזו הכנתי rpmים ל־3 הפצות (Fedora, Suse, CentOS) כולל מספר גרסאות וגם הכל עבור שתי ארכיטקטורות: x86 ו־x86_64.
http://download.opensuse.org/repositories/home:/artyom-beilis/
מה שנותר... להבין כיצד משתמשים בשירות עבור debים
שוחררה גרסה יציבה 1.0.0 של CppCMS המופצת תחת רישיון כפול
היום, אחרי מספר שנות פיתוח, שוחררה גרסה יציבה של CppCMS 1.0.0, אחרי תקופה ארוכה של גרסאות בטא. הגרסה הזו מהווה אבן דרך משמעותית בהתפתחות של CppCMS, הן מבחינה טכנולוגיות והן מבחינה עסקית.
החל מגרסה 1.0.0, ספריית CppCMS תהיה זמינה תחת רישיון חופשי LGPLv3 ותחת רישיון מסחרי שיאפשר פיתוח יישומים קנייניים תוך שמירה על שלמות המוצר והגנה על הסודות המסחריים שלו.
למידע נוסף על הרישוי החלופי והמחירים אנא כנסו לאתר שלנו:
http://commercial.cppcms.com
גרסה זו, עברה שכתוב יסודי ושינויים ארכיטקטוניים עמוקים שהזניקו את הפופולריות שלה מיד עם שחרור גרסאות בטא ראשונות. מבין החידושים הטכנולוגיים:
- הכנסה של API ו־ABI יציבים
- תמיכה מובנית ב־Ajax ו־Comet
- שיפורים מהותיים בלוקליזציה
- תמיכה מובנית ב־Windows
- שיפורים משמעותיים באבטחה: מסנני XSS וכלים למניעת CSRF ועוד.
- שרת HTTP מובנה לפיתוח ומערכות משובצות
הענף הישן יציב CppCMS 0.0.x לא נתמך יותר. כל משתמשיי הענף הישן מתבקשים לעבור לגרסה החדשה. יש לציין, לא ידוע לי על משתמש אחד שנשאר עם הגרסה הישנה.
על nginx ועל symbolic links
בעקבות הכתבה של עופר כהן הגעתי לטבלת השוואה מעניינת בין Apache לבין nginx. מה שהפתיע אותי זה שכדי להעביר קובץ http://example.com/site/files/images/layout/header.png השרת nginx מבצע קריאת stat בודדת. הטבלה עשתה השוואה עם apache שעשה O(n) קריאות עבור תיקיה בעומק n לעומת O(1) עבור nginx...
ברגע שראיתי את זה נדלקה לי נורת אזהרה! מה עם symbolic links?
הסבר: נניח אני איצור קישור סימבולי בשם mypicture.png שיפנה ל־/etc/passwd או לקובץ רגיש אחר, אז ע"י גישה לקובץ תמים אני אוכל לקרוא כל קובץ שיש לשרת web הרשאות לקרוא.
לכל השרתי web יש אופציה לא לעקוב אחרי קישורים כאלה מטעמי אבטחה וזאת גם אופציה מומלצת לעבודה. מה חשוב, זה שבלתי אפשרי לעשות בדיקה כזו ב־O(1) קריאות מערכת ההפעלה (לפי עומק התיקיה).
אז החלטתי לבדוק בעזרת strace, כמה קריאות stats בפועל מבצעים apache, lighttpd ו־nginx כשהאופציה כזו מופעלת וגיליתי... ש־nginx בכלל לא תומך באופציה כזו! קרי הגדרת אבטחה בסיסית שכל שרת אינטרנט החל מ־apache ועד ל־thttpd תומכים בו (אגב גם השרת הפנימי של cppcms) בכלל לא מופיעה בו!
התשובה (רוסית) של מפתח nginx היא להשתמש ב־mount -o nosymfollow עבור מערכת הקבצים כדי לעקוף את הבעיה.
חבל...
